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