KDE_NO_EXPORT

Thiago Macieira thiago at kde.org
Tue Jul 25 17:09:45 BST 2006


Thomas Zander wrote:
>On Tuesday 25 July 2006 16:13, Kuba Ober wrote:
>> I guess that Allen's idea was to make things less redundant. If a
>> class etc. is marked as private in the doxygen comments etc., then
>> maybe it'd be simpler to have a macro similar to the one used to mark
>> the class as public.
>
>I'm not clear on what you are saying here; when is a class private
>according to the api docs ?   And I don't mean a sentence "Do not use!"
>but a formal one.
>I personally don't know any way to do that.  And I was under the
>impression that the macro is and will be the only marker for "You can
> use this outside this library!".

I don't agree with that. There are perfectly valid reasons for a private, 
exported class. So the fact that a class is private doesn't mean it has 
to be NO_EXPORT.

That said, however, private exported classes are ugly hacks -- just a 
little less ugly than global, private and undocumented functions. They 
should be avoided if possible.

On the other hand, there can be no such thing as public, unexported 
classes.

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060725/d5fe0de0/attachment.sig>


More information about the kde-core-devel mailing list