Library guidelines

[Frerich Raabe]

On Thursday 16 March 2006 10:52, Thiago Macieira wrote:
> >By convention, the private class will be called Private and will be in
> > the class definition.
>
> I'd like to ask that that be scrapped. The guideline should be:
> "By convention, the private class will be named the same as the public
> class, with "Private" appended to the name. It must not be a nested
> class."
>
> Why? Because if you do this:
> class KDECORE_EXPORT KMyClass
> {
>   class Private;
>   Private * const d;
> ...
> };
>
> then KMyClass::Private is exported too, which is something we'd like to
> avoid.

Hm, I'm a bit surprised that this is the case. If you use visibility=hidden 
when defining KMyClass::Private, it still gets exported just like KMyClass? I 
would have thought that to the linker (who, if I understood all this 
correctly, is the one who strips symbols with hidden visibility [unlike with 
static symbols]) it doesn't make a difference whether a class is callied 
QuakPrivate or Quak::Private, it's going to be mangled anyway.

> In the "Static objects", I'd like to add:
> "Try to avoid creating static arrays of strings because they incur in
> extra relocation at load-time. Example of code to avoid:
>
> static const char *messages[] = {
>   "message1",
>   "message2",
>   0
> };
>
> This type of coding should be avoided if possible. The example above could
> be replaced by a list built at first use (in which case you could use a
> QList<QByteArray> too) or by a switch.
>
> However, it is preferred to use this practice if the alternative is code
> that is of difficult readability and/or maintenance."

You could also use one long string and an array of offsets:

static const char stringData[] = {
	"message1\0",
	"message2\0",
	0
};

static int stringDataOffsets[] = {
	0,
	9
};

static const char *message( int no ) {
	return stringData + stringDataOffsets[ no ];
}

Then you don't have to relocate anything at all, and all data can probably 
(I'm not sure, but I'd guess so) be put in non-writeable (shareable) memory 
pages, yet you don't have a runtime cost as with QList<QByteArray> or 
something else. I think moc does something like that with Qt 4.x as well.

-- 
Frerich Raabe - raabe at froglogic.com
www.froglogic.com - Qt consulting and add-ons