cullmann at babylon2k.de
Sun Oct 2 19:21:58 BST 2005
On Sunday 02 October 2005 18:57, Cornelius Schumacher wrote:
> But if the policy is "Move all private members to private classes" I would
> object, because this thread shows that there are no clear benefits and it
> is more a question of personal coding style.
No, it's not. If you code with spaces or tabs, that won't be visible neither
in the resulting binaries nor API.
But the d-pointer stuff really makes keeping BC much more easy, and we care
for BC, do we? You can argue: Yes, we let d-pointer around, but please make
no rule to enforce to use if for all private stuff. But than we end up with
members in the class we must keep around for the whole 4.x release cycle,
just because some developer thought it should be there in 4.0, but we don't
need it anymore say in 4.1. In addition, people can't mess around with the
hidden stuff in the d-pointers that easy as with the #define private public
I think a common coding guideline for kdelibs which enforces usage of the
d-pointer for all private members sounds sane, the headers stay clean, the
stuff is better hidden and BC keeping is made more easy.
KDE Developer, kde.org Maintainance Team
http://www.babylon2k.de, cullmann at kde.org
More information about the kde-core-devel