D pointers

[Ingo Klöcker]

On Monday 03 October 2005 11:52, Stephan Kulow wrote:
> 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.

Moreover, it will be much easier to hack on the code if d-> is used 
consistently. Otherwise you'll always have to remember (or try) whether 
you have to write mFoo or d->foo.

Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20051003/63ca7ebb/attachment.sig>