DRAFT document on coding conventions in kde libraries
Harald Fernengel
harry at kdevelop.org
Sun Mar 5 19:07:44 GMT 2006
Hi,
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.
Wrong:
static QString foo; // wrong - object might not be constructed
static QString bar("hello"); // as above
static int foo = myInitializer(); // myInitializer() might not be called
Right:
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.
Harald
More information about the kde-core-devel
mailing list