D pointers

Stephan Kulow coolo at kde.org
Mon Oct 3 10:52:29 BST 2005

Am Montag, 3. Oktober 2005 11:43 schrieb Cornelius Schumacher:
> On Monday 03 October 2005 08:19, Lars Knoll wrote:
> > On Sunday 02 October 2005 18:57, Cornelius Schumacher wrote:
> > > But if the policy is "Move all private members to private classes" I
> > > would object, because this thread shows that there are no clear
> > > benefits and it is more a question of personal coding style.
> >
> > The benefit is the greater refactoring possibilities you have. I can only
> > say that from past 5 years of coding in Qt I have missed this possibility
> > quite a few times just because a member happened to be in the class and
> > not the d pointer.
> But if you need different private variables for a refactoring you can
> always create them in the private class. The worst thing that can happen is
> that you have unused variables in the class. If that is uglier than having
> to write "d->someVariable" and having to take care of destructors, copy
> constructors, assignment operators, instead of simply using "mSomeVariable"
> is basically a matter of taste, I would say, and so a bad subject for a
> policy.
One should note that you need to write a destructor and the assignment 
operators anyway, as otherwise you have no guarantee that the compiler will
destruct the class even if you exchange the lib without recompiling the apps 
later. So the only ugliness saved is the indirection and I would say one gets
easily used to it - but yes, I don't want to enforce anything either. I just 
want an open discussion and figuring what will be policy and what not.

Greetings, Stephan

More information about the kde-core-devel mailing list