ahartmetz at gmail.com
Wed Feb 6 23:42:01 GMT 2008
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
> 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...
More information about the kde-core-devel