DRAFT document on coding conventions in kde libraries

[Thiago Macieira]

Allan Sandfeld Jensen wrote:
>On Monday 06 March 2006 10:44, Thiago Macieira wrote:
>> Allan Sandfeld Jensen wrote:
>> >It is unreliable across shared libaries. If you have a non-QObject
>> > based heirachy you should implement your own type-system rather than
>> > rely on dynamic_cast.
>>
>> I'd rather people used dynamic_cast<> rather than write and rewrite
>> their own system.
>>
>> They just have to be warned against the pitfalls that it may
>> represent. In special: do not ever use dynamic_cast in a class that is
>> not marked _EXPORT.
>
>I don't think that will help with dlopen'ed libraries or plugins.

You said libraries. So let's make the distinction clear here:

- Libraries are those that you link to and NEVER dlopen.
- Modules are those that you dlopen and NEVER link to.
Those are the only two options.

You're safe using dynamic_cast<> across libraries, as long as the classes 
are exported. It's even possible to use dynamic_cast if the object is an 
unknown, non-exported class, as long as the class you're trying to cast 
it to is exported.

You're also safe using dynamic_cast<> across modules as long as you're 
casting the object to an exported and well-defined class: this class MUST 
have a virtual destructor and its typeinfo MUST be in a library (which 
means there must be at least one non-inline virtual method in it). I hope 
I'm not wrong here.

You're not safe using dynamic_cast<> across modules if the above isn't 
respected.
-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

1. On frumscafte, hwonne time_t wæs náht, se scieppend þone circolwyrde 
wundorcræftlíge cennede and seo eorðe wæs idel and hit wæs gód.
-------------- 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/20060306/1926b58d/attachment.sig>