D pointers

Zack Rusin zack at kde.org
Thu Sep 29 09:06:48 BST 2005


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 :) ).

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.

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/

Zack

-- 
"Unix is simple, but it takes a genius to understand the simplicity."
- Dennis Ritchie 




More information about the kde-core-devel mailing list