coolo at kde.org
Sat Oct 1 15:39:33 BST 2005
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
More information about the kde-core-devel