D pointers

Simon Hausmann hausmann at kde.org
Mon Oct 3 10:47:38 BST 2005

On Monday 03 October 2005 11:43, Cornelius Schumacher wrote:
> 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.

The problem I see with leaving unused variables around in classes is that the 
compiler doesn't warn you when you accidentially use them. Usually not 
initialized anymore then you're quickly in trouble when you write mVariable 
instead of d->newVariable.

Besides that it probably doesn't hurt for integers and other primitive types, 
but if you have more complex types you still waste constructor and destructor 
time on them even if they're unused.


More information about the kde-core-devel mailing list