KDE/kdelibs/kdeui/jobs

[Lubos Lunak]

On Thursday 09 of April 2009, Michael Pyne wrote:
> On Wednesday 08 April 2009 13:40:36 Andreas Pakulat wrote:
> > 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 signature.

 That's right, but it doesn't matter for private functions, since they are 
private :). The case only I can think of is an inline function refering to a 
private one (which is a very unlikely case for a slot).

> > 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. :)

 Not really. E.g. private virtual functions don't tend to be very useful :). 
The only arguments that can hold are the recompile times and playing safe 
instead of analyzing 
http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++ for 
people who don't know it off-hand.

-- 
Lubos Lunak
KDE developer
--------------------------------------------------------------
SUSE LINUX, s.r.o.   e-mail: l.lunak at suse.cz , l.lunak at kde.org
Lihovarska 1060/12   tel: +420 284 028 972
190 00 Prague 9      fax: +420 284 028 951
Czech Republic       http://www.suse.cz