D pointers

[Frans Englich]

On Saturday 01 October 2005 14:39, Stephan Kulow wrote:
> 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?).

Sounds sensible to me. This could also be combined with moving private 
functions into the the private class. (Yes, a list of this is needed.)

(I also put my vote for all changes that makes BC easier and development more 
flexible, except for the cases where clear numbers states there's a 
performance advantage that weights heavier.)

> We should only leave members we're 1000% sure they will stay 

The problem is that there's no class where its developer say "I know this 
member must be changed in the next minor release and therefore I need a 
d-pointer." The point with d-pointers is exactly to save the case where the 
developer thought "I thought I was god and knew everything, but gee, I didn't 
predict this." So, it should be more like 10000%..

I would say it's not enough that a member is claimed to never change. There 
must also be a measured gain of folding it in; if changing a member would 
change the "nature" of the class, I suppose it would be ok. Perhaps a thumb 
of rule is:

"If putting a member inside the class have been /measured/ to be a performance 
gain, and that changing the member would also require changing another part 
of the class' BC interface, such as a function signature, it is ok to not put 
it in a d-pointer structure."

I stress d-pointers because it's highly relevant in KDE. KDE's development is 
done by a wide spectrum of developers with different experiences and not 
everything is reviewed(and so forth). d-pointers are a much needed safety net 
for compensating this chaotic development, in my opinion.


Cheers,

		Frans