protected d-pointers

[Andreas Hartmetz]

Am Mittwoch 06 Februar 2008 23:50:49 schrieb Richard Moore:
> On 2/6/08, Matthias Kretz <kretz at kde.org> wrote:
> > I suggest we require kdelibs classes to only use protected d-pointers so
> > that the shared-d-pointer pattern can be used when needed. Once we need
> > to keep BC on Windows we cannot change private members to protected
> > members anymore. So we can still do this now...
>
> Surely this defeats the point? If we are making the d-pointer part of
> the defined API then we might as well not have them at all.
Protection can's stop fools, it is there to guide reasonable people. 
Reasonable people wouldn't mess with the d-pointer even if it was public. You 
can't do much with it anyway if you don't know the layout of the private 
class.

> Please 
> could you make it clear what we would gain by this?
>
First off, I only see an advantage for classes with more than one level of 
inheritance inside kdelibs. There are not many AFAIK.

You can derive the private class of a subclass from the private class of the 
superclass to avoid effectively having a private class and d-pointer member 
for every single inheritance. That makes sense because a) you don't have to 
waste memory for a cascade of d-pointers and b) because memory allocations 
(one per private class) are quite expensive.

Another thing that should be added is that Windows compilers traditionally 
encode the complete method signature in a method's mangled name. Therefore 
changing protection changes the mangled name -> Bam, link failure.

And finally: Data protection is purely a compile-time thing - there are 
techniques to overcome it. Are there reliable ones for private members?
I know a trick for protected members that doesn't work for private...