D pointers

[Christoph Cullmann]

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 
hack.

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.

cu
Christoph

-- 
Christoph Cullmann
KDE Developer, kde.org Maintainance Team
http://www.babylon2k.de, cullmann at kde.org