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