[Ctk-developers] Q_DISABLE_COPY policy?
    Sascha Zelzer 
    s.zelzer at dkfz-heidelberg.de
       
    Fri Apr 23 16:06:50 UTC 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