DRAFT document on coding conventions in kde libraries

Harald Fernengel harry at kdevelop.org
Sun Mar 5 19:07:44 GMT 2006


On Sunday 05 March 2006 14:27, Olivier Goffart wrote:
> What have i forget ?

Since we export complete classes and all symbols they contain, I'd opt for 
making the Private classes stand-alone and not subclasses. This will make 
sure that all private stuff will be optimized away and not end up as symbol.

Another point that struck me hard when doing cross-platform development: 
Global static objects in libraries should be avoided at all cost. You never 
know when the constructor will be run or if it will be run at all.

static QString foo; // wrong - object might not be constructed
static QString bar("hello"); // as above
static int foo = myInitializer(); // myInitializer() might not be called 


static const int i = 42;
static const int ii[3] = {1, 2, 3};
static const char myString[] = "hello";
static const MyStruct s = {3, 4.4, "hello"};

You can use Q_GLOBAL_STATIC to create a global static objects which will be 
initialized the first time you use them.


More information about the kde-core-devel mailing list