D pointers

[Shaheed]

On Thursday 29 September 2005 09:06, Zack Rusin wrote:
> We were just talking about this discussion a bit and I think it makes
> sense to discuss it in a wider crowd.
>
> For those who are not on kde-commits the question was "for KDE 4 should
> we start flattening d-pointer hierarchy".
>
> On Wednesday 28 September 2005 22:31, Stephan Kulow wrote:
> > The same about malloc: the more a class is created, the more the
> > private d pointer hurts. And fortunately classes like KURL that we
> > still create a lot is not creating a Private - and that has to stay
> > this way.
>
> KURL is actually the best example of why we should use d-pointers, not
> the other way around. Lars can tell you more about his futile attempts
> of optimizing this class (making it use lazy-parsing). Everything is
> inlined so we couldn't do anything. QUrl does create a Private and is
> probably around 10x faster so maybe you should find a different example
> of where not using a d-pointer was beneficial for KDE (in fact I dare
> you to do so :) ).

All this example merely shows that algorithmic/design changes can make a huge 
difference. Anything facilitated by a d-pointer can just as easily be done 
with a member variable, and without the extra allocation/indirection.

Inlining is really a red-herring here: a d-pointer just makes inlining 
"harder": it not the design intent for it. (I personally have seen few cases 
where inlining is a genuine overall win, but they apparently do exist).

My argument for flatten-where-possible is based on the need for extra 
allocations and indirections.

> Yes there are special cases, in container classes for example, but those
> are _very_ rarely if ever in KDE (in fact I don't remember anything of
> the top of my head that would be it).
>
> Flattening d-pointers really doesn't make too much sense. You will still
> keep a malloc overhead because by KDE 4.1 almost all our class would
> need it anyway and lose the flexibility right of the bat.

This whole question arose because of an email that casually seemed to suggest 
that moving *all* private members to the d-pointer was a good idea, on the 
basis of reduced compile times and so on. That seems just plain wrong to me. 
given the overhead.

I don't know what you mean by loss of flexibility: I never proposed getting 
rid of the d pointer - only not using it when possible.

> Also if you want real world example of what kind of effect porting of Qt
> 3 app to Qt 4 has look at:
> http://blogs.qtdeveloper.net/archives/2005/08/24/qsa-120/

Nice anecdote, but beside the point. Even without a convenient algorithm 
change, if you start with a non-empty d-pointer structure and you flatten it 
out, you will go faster.

Thanks, Shaheed