[Ctk-developers] Q_DISABLE_COPY policy?

[Julien Finet]

Q_DISABLE_COPY is documented (not internal API), so no worries :-)

Concerning Q_DECLARE_PRIVATE and others, the current implementation of these
macros in CTK works fine but it doesn't allow inheritance of private
implementations. This is something quite handy sometimes but not necessary
(inheritance of protected methods in the public class can be used instead).
However we could probably come up with our own version of these Qt macros,
so we won't depend on Qt private API (not only they are not public API but
they also are LGPL that prevent us to use them).

Whatever we decide, we won't be able to derive from Qt private
implementations as they are not public API.

Julien.

On Thu, Apr 22, 2010 at 4:18 PM, Sascha Zelzer
<s.zelzer at dkfz-heidelberg.de>wrote:

>  Hi,
>
> we also had a short discussion about the Q_DECLARE_PRIVATE macro and
> friends. JC initially used macros and template classes adapted from Qxt (the
> CTK_DECLARE_PRIVATE etc. macros and the ctkPrivate template class). I
> haven't had a look at them in detail yet, so I don't know what their
> benefits are compared to the Qt "native" way.
>
> The only thing about which I am a little bit worried is that
> Q_DECLARE_PRIVATE, Q_D, Q_P, Q_DISABLE_COPY etc. is not public API (e.g. it
> is not documented in the official Qt docs). However, I think many people use
> them and are familiar with them. Shall we use familiar, but non-official
> features of Qt or roll our own macros?
>
>
> See for example this discussion:
>
> http://lists.trolltech.com/qt-interest/2007-09/thread00325-0.html
>
> The interesting part is:
>
> > On 14.09.07 13:49:48, Thiago Macieira wrote:
> > > Note of warning: Q_DECLARE_XXXX are not documented. You're not supposed
> > > to use them.
> >
> > Yet they are documented and advertised to be used on
> > http://techbase.kde.org/Policies/Library_Code_Policy#D-Pointers
>
> Let me put my KDE hat.
>
> ===> KDE developer speaking <===
> I know. I wrote that potion of the policy.
>
> KDE is using those macros. KDE is also using other non-documented features and
> functions in Qt.
> ==========
>
> However, as a Trolltech developer, I have to tell you: those macros are
> undocumented. Trolltech can change them from one release to the next. What's
> more, if you have a problem with them and mail qt-bugs at xxxxxxxxxxxxx or
> support at xxxxxxxxxxxxx, the support engineers will tell it's internal API and
> they can't help you. (Though, of course, they'll be more polite than me)
>
> KDE is at its own risk doing that. And the side-effects of that have shown up
> recently: take a look at this change in that very same page:http://techbase.kde.org/index.php?title=Policies%2FLibrary_Code_Policy&diff=13707&oldid=13098
>
> I removed the notice about QAtomic. Why? Because QAtomic -- an undocumented
> class in Qt 4.0 through 4.3 -- has disappeared in Qt 4.4. And KDE is using
> it.
>
>
>
>
>
> On 04/22/2010 08:28 PM, Julien Finet wrote:
>
> Good idea !
> If we have to follow the Qt naming convention for classes that derive from
> Qt, then we should probably use the same keywords...
> Julien.
>
> On Thu, Apr 22, 2010 at 2:14 PM, Arnaud GELAS <
> arnaud_gelas at hms.harvard.edu> wrote:
>
>> Hi,
>>
>> I just wanted to know what's the policy for constructor by copy?
>> Do you want to use Q_DISABLE_COPY macro declared in private?
>>
>> Arnaud
>> _______________________________________________
>> Ctk-developers mailing list
>> Ctk-developers at commontk.org
>> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>>
>
>
>
> _______________________________________________
> Ctk-developers mailing list
> Ctk-developers at commontk.org
> http://public.kitware.com/cgi-bin/mailman/listinfo/ctk-developers
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20100422/37792e76/attachment.htm>