Michael Pyne mpyne at purinchu.net
Thu Apr 9 02:08:50 BST 2009

On Wednesday 08 April 2009 13:40:36 Andreas Pakulat wrote:
> On 08.04.09 18:25:27, David Faure wrote:
> > On Wednesday 08 April 2009, Andreas Pakulat wrote:
> > > On 08.04.09 14:08:26, Lubos Lunak wrote:
> > > >  How does changing a private: slot affect binary compatibility in any
> > > > way?
> > >
> > > Hmm, guess I need to be more explicit, of course I only meant the
> > > signature, not the actual implementation.
> >
> > That's what Lubos meant too ;)
> > And he's right in theory, changing the signature of any private method is
> > fine.
> Hmm, can't test right now, but I was under the impression that any private
> methods of exported classes show up in the symbol list of the library -
> maybe not on all platforms.

I'm pretty sure this is definitely true on Windows/MSVC, Thiago would probably 
know better though.  According to 
http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++ the 
accessibility of a function (i.e. public/protected/private) may be part of its 

> I mean else there wouldn't be any reason (aside
> from design decisions, like locality) to put methods into the d-pointer and
> it could be purely a data container for private members.

Nah, there's plenty of reasons.  It allows us to remove dead code, add/reorder 
virtual functions all willy-nilly, reduces recompile times since we're 
changing .cpp files instead of .h files, the list goes on really. :)

 - Michael Pyne
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20090408/5cab6a15/attachment.sig>

More information about the kde-core-devel mailing list