[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
SC.
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
BC.
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