D pointers

[Stephan Kulow]

Am Dienstag, 29. Juni 2004 01:00 schrieb Lubos Lunak:
> Can we now discuss other issues of the problem, if there are any?

OK, let me post a conclusion: 
 - inline is bad as it removes all kind of BC flexibility we have
 - without inline, the price of d pointers are: one more malloc 
     (can only be spared in KDE 4.0 and is likely to return, so 
     it's a little price and there is no guarantee to be kept - so we
     better optimize _with_ it already included) and the extra 
     indirection that a d pointer brings (this->member becomes
     this->d->member). The latter is the real problem
 - the benefit of a d pointer (for everything) is cleaner header,
   more consistent code as all code is d-> not just that recently
   added and in general greater flexibility.

So we should in general move things to a possibly already existant
Priv class and review classes if it makes sense to move their members
to a Priv class. But we should do this with care (anyone volunteers to post
a list of classes and their number of instances in a typical KDE session?).

We should only leave members we're 1000% sure they will stay where
they are and that having their accessors as fast as possible is a requirement
for a quick desktop. I doubt there are _that_ many - now that Lubos 
benchmarked KURL. 

Greetings, Stephan