[Development] Source break policy for function overloads

Thiago Macieira thiago.macieira at intel.com
Thu Jul 14 00:59:51 CEST 2016

Em quarta-feira, 13 de julho de 2016, às 23:29:42 PDT, Richard Moore escreveu:
> On 13 July 2016 at 19:10, Marc Mutz <marc.mutz at kdab.com> wrote:
> > Renaming a public inline function of a non-exported class is BC, but SiC
> > Type
> > (b), so not acceptable.
> ​Good analysis, however isn't the compiler allowed to not inline stuff too
> which would mean this example is not b/c either.

Indeed, but compilers need to emit the out-of-line copy if they decided not to 
inline. That means the previous copy exists for code that wasn't recompiled, 
regardless of whether the class has changed since. That is why it's BC but not 

This applies even for MSVC, for non-exported classes (Marc's case). For 
exported classes, MSVC in debug mode (unlike the IA-64 C++ ABI) calls the out-
of-line copy without emitting it, which the DLL that exported the class must 
have emitted. That is why removing inline functions in exported classes is not 

It's also why MSVC exports too much from template classes, if you derive from 
it and export (QPolygon and QVector case). I believe it has a nasty Level 4 
warning, about dllexporting a class that isn't dllexported, but we have turned 
it off for at least 10 years.

Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

More information about the Development mailing list