frans.englich at telia.com
Sat Oct 1 17:28:11 BST 2005
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.
More information about the kde-core-devel