[Ctk-developers] Q_DISABLE_COPY policy?

Sascha Zelzer s.zelzer at dkfz-heidelberg.de
Fri Apr 23 12:06:50 EDT 2010


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



More information about the Ctk-developers mailing list