[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