Advice needed on BIC

Alexander Neundorf neundorf at
Tue Dec 14 19:53:50 GMT 2010

On Tuesday 14 December 2010, John Layt wrote:
> Hi,
> I'm been reading the BIC techbase pages again to make sure the api changes
> I've done in 4.6 won't cause problems.
> I had always thought it was BIC safe to 'promote' api to less restricted
> access levels, however I notice now that this doesn't work under Windows
> and so is now considered BIC unsafe:

I'm not sure we really already care about keeping BC on Windows.
Windows guys: do we ?

> "[You cannot change] the access rights to some functions or data members,
> for example from private to public. With some compilers, this information
> may be part of the signature. If you need to make a private function
> protected or even public, you have to add a new function that calls the
> private one."
> Now, I've introduced some private functions in the 4.5. and 4.6 that may
> eventually be made public, so for the 4.6 ones I'm going to rename them
> fooPrivate() or something similar, but I'm wondering about the 4.5 ones, am
> I able to rename them too in a BIC safe way?  The reason I ask is the page
> is slightly contradictory:
> "[You can] remove private non-virtual functions if they are not called by
> any inline functions (and have never been)."
> versus
> "[You cannot] For existing functions of any type ... remove it."
> Can someone clarify for me which is correct?

A private function cannot be called by anybody outside the class, it can only 
be called from within the class, so private symbols should not make it into 
any user of the class, so removing private functions should be ok.
But if the private function is called from an inline function, then the call 
actually moves into the calling code, so it now references the private 
function, and BC would break if it was removed.
(I experienced something similar with std::string and different  versions of 
STL recently, a STL-standard function was implemented inline and called a 
private non-standard function... :-/ )


More information about the kde-core-devel mailing list