Blog layout changed

I wasn't entirely happy with the previous template in terms of readability, so I've gone to a layout with less contrast and colors that are easier on the eyes (less dark grey and blue, more tan).

Now, if I can only get it to be a single column...

edit: success!

Compile-time size determination

WARNING ugly hack ahead! WARNING

I have a project that has two components, written in two languages, that execute in two different execution environments (PPU and SPU). One component is written in C++ and the other in assembly and since data is passed back and forth fairly regularly the C++ component has a ton of static assertions validating structure size and offsets in the hope that if anything breaks it is caught early.

Finding initial, or updating existing, structure offsets and sizes was tedious. Using printf() worked but the whole project would have to build, it'd be better if it would just fail at compile time with the numbers I needed. Oh, hey, templates might actually work here...

Say, I had:

struct Foo {

// some number of fields here

};

Then:

template

struct fail

{

enum { value = a / 0 };

};

fail f1;

Would give me both this:

test.cpp:13: warning: division by zero in 'a / 0'

test.cpp: In instantiation of 'fail<136u>':

... and a slightly dirty feeling.

(Blogspot still sucks for posting code.)

Retailers angry about Steam; consumers shrug.

Some British retailers are all in a snit about Steam and are threatening to not carry titles that are sold online.

I'm not quite sure how this is any different than the way things are now. The last time I stepped into a video game store the PC games section was non-existent save for the token Sims copy, replaced almost entirely with used copies of Gears of War and Halo.

Buying games in a store used to be a treat, you'd get a well designed box loaded with a decent manual, perhaps a book detailing the back story, and sometimes collectors memorabilia. Before the days of the collectors edition that's what you would get if you bought the normal run-of-the-mill standard edition.

Now game boxes contain nothing but the slimmest of slim manuals (soon to disappear, mark my words), and an online activation code. This is somewhat understandable as video game prices have remained static in the last 15-20 years even in the face of ever increasing costs and inflation.

Buying online saves the trip to the mall, waiting in line, pre-ordering, you name it. I get the game I want, when I want, and these days I'm not missing any part of the experience.

Retailers are free to stop carrying PC games but, really, they already stopped three years ago.

My Five Rules of Corporate Communication

I wrote these mostly with email in mind but some apply just as well when dealing with others in person.

Rule #1: Always be sincere and professional.

Sarcasm doesn't convey well on email or any medium where your audience can't read your body language or receive any speaking cues. This especially applies if your targeted audience isn't familiar with you; although your team might understand and laugh when you're sending out the latest Daily WTF found within your own code base with a snide "yeah, THAT was a good idea" attached but the company-wide developers mailing list likely won't.

Rule #2: Assume people are sincere and professional.

This rule just follows from the first. If you are sincere and professional, other people will be sincere and professional to you.

Rule #3: Assume people keep what you send.

My first manager told me that it might be helpful to keep all the email you ever receive. Boy howdy was he ever right. Not only do I have a wealth of information at my fingertips to search through but it has saved me a few times from people getting away with "No no no, I didn't say THAT...". It also helps when dealing with some people whose turnaround on support issues is a day or two longer than Outlook's auto-delete policy.

This, in turn, has me thinking now that I cannot get away with the same dodge because someone out there will have my original email archived and will call me on my BS. Outlook, like the elephant it is, also never forgets -- beware that the rant you send out may not find its way into the bit-bucket in the sky when you hope it does.

Rule 4: Email conversations are meetings.

Well, almost. The big difference is that there's no one to cut you off in the middle of your diatribe and say that it's Dave's turn to write. Have a point or agenda. Don't beat around the bush. If you diarrhea'd three pages of text to the screen and still haven't reached your point then it's time for some editing. It doesn't just take time for you to write your novella but it also takes many people lots of time to read it. Email, like meetings, takes up time.

Rands in Repose has a great piece on running meetings. In it he says that a well run meeting is one that needs to never happen again. The same applies to email.

Rule 5: Consider your audience.

Double check that you are addressing the right people. Does your boss's boss really need to know that Bob broke the build? Probably not.

Use To:/Cc: properly. Put someone on a To: line if you expect a reply from them, Cc: if you just want them to be aware of what's going on.

Pimples are annoying, C++ Clearasil wanted

Hating C++ seems to be the cool thing to do these days and though I can understand why the sentiment exists, I don't share it. One area I often think is lacking though is the ability to really hide private data without reverting to writing C. Not that I think there's anything wrong with writing C but in a codebase that's largely C++ it can look somewhat out of place.

Idiomatic C and C++ differ quite significantly in the way interfaces are exposed to end users. In many cases with C people use declared structures as opaque handles, preventing end users from mucking around with internal structures. External header files for libraries end up looking something like this:

struct foo;

struct foo *foo_create(int a);

void foo_destroy(struct foo *foo_instance);

int foo_method(struct foo *foo_instance, const char *string, int count);

As a user of this code I have no idea what state foo encapsulates because the library author has made it clear that it isn't something that I should worry about.

C++, though, encourages exposing data by bundling all types and methods of a class into the public declaration.

class foo {

const char *m_string;

int m_count;

bar &m_barInstance;

public:

foo(int a);

~foo();

int method(const char *string, int count);

};

The world now knows what foo contains, whether they need to or not. The idiomatic method of hiding internal details in C++ is to use pointers-to-implementation (pimpl) patterns. These do clean up the class declaration a bit:

struct foo_impl;

class foo {

foo_impl *m_implementation;

public:

foo(int a);

~foo();

int method(const char *string, int count);

};

And behind the scenes, in foo.cpp:

struct foo_impl {

const char *m_string;

int m_count;

bar &m_barInstance;

};

foo::foo(int a)

: m_implementation(new foo_impl)

{

m_implementation->m_count = a;

};

The two big downsides with pimpls are that now every allocation of foo comes with a second allocation of foo_impl, and also that our code is littered with m_implementation.

What I wish C++ had was a way to export the public interface of a class without any consideration to storage or to its own private functions. Something like this:

static_interface foo {

int method(const char *string, int count);

};

I really want to avoid having the extra indirection of a pimpl pointer or indirect jump if it were to just be an interface but while still having the convenience of being able to write foo_ptr->method("hello", 5). This would mean that it could only be used as a pointer/reference but that's no different than with the C example above.