On quinta-feira, 30 de março de 2017 02:40:53 PDT Marc Mutz wrote: > Ok, not 100% transparent in all cases, then. But a symbol comparison like we > do before a release will highlight this.
I'm assuming you're talking here about the library whose binary compatibility gets broken: we do a header diff, not a symbol diff. We wouldn't catch this at the headerdiff time because the namespace is inline, so the functions that were affected were not changed at all. In fact, the headers that declare those functions may be completely unmodified. Aleksey does run the ABI checker tool that does show symbols. Show of hands, how many of you have clicked his links in the last year? Now, if you're talking about the library that has the inline namespace, then yes, we'd catch it. We'd see a change in inline namespace. And our BC rules should require is to revert that change and keep the inline back to the original. > Anyway, apart from transparency: how is that different from QFoo followed up > by QFooV2? Implicit (opt-out) vs explicit (opt-in). One is a silent change downstream and causes silent breakage unless everything gets recompiled. Even if you know that this is a problem and is going to happen, you can't prepare for it until the new class appears, so a recompilation is still needed. That's what happened in the std::string vs std::__cxx11::string problem. In the other, it's explicit. Code that used to work continues to work, whether it's recompiled or not. There's no need to insert code to prepare for the update and recompile at the right time. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development