Library guidelines

Thiago Macieira thiago at kde.org
Thu Mar 16 10:51:26 GMT 2006


Frerich Raabe wrote:
>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?

On Unix I can confirm that it gets a hidden visibility, but I am not sure 
on Windows. Someone will have to test.

But I wouldn't be surprised if it inherited the visibility from the 
parent.

> 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.

Right, but it's the compiler that tells the linker whether a symbol has 
default or hidden visibility.

>> 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
>};

You mean without the commas there and the final zero.

>
>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.

Yes, that's what moc does.

That's fine for generated code, but that's really hard to maintain in 
hand-written code. If you change one string, you have to update all 
offsets from there until the end.

That's a trade-off: either you get code readability or you get less 
relocations.

-- 
Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
  thiago.macieira (AT) trolltech.com     Trolltech AS
    GPG: 0x6EF45358                   |  Sandakerveien 116,
    E067 918B B660 DBD1 105C          |  NO-0402
    966C 33F5 F005 6EF4 5358          |  Oslo, Norway
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060316/413d70d3/attachment.sig>


More information about the kde-core-devel mailing list