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