[Ctk-developers] Q_DISABLE_COPY policy?

[Julien Finet]

My bad, I thought the macros were not accessible from the public API, but
they actually are (in qglobal.h), they are "just" not documented/supported.
So nothing prevent us from using them.

Considering the fact that Qt doesn't seem to be very strict about
backward compatibility (i.e. Qt3 to Qt4) anyway (however things could change
since the acquisition by Nokia), I would then vote in favor of using these
macros.

But I guess we are touching here a philosophical question about CTK.

Julien.

On Fri, Apr 23, 2010 at 12:06 PM, Sascha Zelzer <s.zelzer at dkfz-heidelberg.de
> wrote:

> Hi,
>
>
> On 04/22/2010 10:57 PM, Julien Finet wrote:
>
>> Q_DISABLE_COPY is documented (not internal API), so no worries :-)
>>
>
> Right, I have overlooked this one.
>
>
>
>> 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).
>>
>
> I see. I already use private inheritance for some classes in the
> plugin-framework branch (by using Q_DECLARE_PRIVATE etc.), so we would have
> to work something out in order to have a common code style.
>
> Apart from the inheritance issue, the only advantage of the current CTK
> macros (as far as I can see) is, that they additionally take care of
> initializing and deleting the d-pointer (and adding a few convenient
> methods). I would prefer to duplicate the Qt macros and maybe extend them if
> needed. They seem to get the job done and a lot of people are already
> familiar with their usage.
>
>
>  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).
>>
>
> I don't get this point. Are you saying that we cannot use macros from a
> LGPL library because they expand to LGPL'ed code inside our own? Then what
> about the "official" macro Q_DISABLE_COPY?
>
>
>
>> Whatever we decide, we won't be able to derive from Qt private
>> implementations as they are not public API.
>>
>>
> Yes, that is obvious :-)
>
> Best,
>
> Sascha
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ctk-developers/attachments/20100423/0ad9d806/attachment.html>