Singletons considered harmful to your health

The phone architecture that I’m compiling TexasHoldem for is very stingy when it comes to linking. Basically any data that is in the .data or .bss segments is verboten. Symbian OS apps are compiled as shared object code and doing the copy-on-write logic for shared static data is too much work for these lowly devices. This has caused me a bit of anguish as I made lots (far too many) static code optimizations and the core game engine objects are singletons. Of course all this is just tedius to cleanup but shame on me for not researching this ahead of time.

Here’s the conversions that I’ve made in order of difficulty:

First conversion, helping compiler remove .data segments with const:

static uint [] card_seq { … } Becomes: static const uint [] card_seq { … }

static const char * string_table {} Becomes: static const char * const string_table {}

Second conversion, removing uninitailized data in the .bss segment:

void single_threaded_converter(byte *buffer, uint32 size) { static byte more_than_buf[1024]; // becomes stack variable or input variable … }

Third conversion, converting singletons to explicit initialization: ** class MyEngine { static MyEngine &instance(); };

Becomes:

class MyEngine { static MyEngine *create(); static void release(MyEngine *p); };

… There is lots of references to cleanup here since lots of stuff likes to refer to engine (yeah I know I’m lazy)

There is a single exported entry to bootstrap your application in SymbianOS. It now creates the engine. There is still the issue of getting sub-system pointers to objects that need them in a clean way. I have to visit the whole object heirachy at this point to clean this up. The funny thing is that I really don’t like singletons that much anyways. This is similar to the wake up call I had when I thought it would be a good idea to use STL in a large production server.