On 04.05.23 00:24, Thiago Macieira wrote: > On Wednesday, 3 May 2023 11:15:19 PDT Marc Mutz via Development wrote: >> That might be so, and I'm not Maurice or Vladimir, but if I was to >> decide, I wouldn't commit my company to a roadmap that requires forward >> binary compatibility from stdlib vendors without a written declaration >> from each of them that this is a supported use-case. > > That problem exists whether we use C++20 or not. If a library decides to break > BC, they'll likely *break* it for all versions. I don't think a C++20 symbol > in 2025 is more likely to get replaced/removed than a C++17 or C++98 one. > > Compiling with a new version of the library and running with an old one is not > and has never been supported. No one is suggesting that. That's why I listed a > few oldest minimum versions, so that anyone interested in creating binary > builds could choose exactly those.
Ah, now I understand. You assume that a C++20 build will use the same DLL/SO/DYNLIB stdlib that a C++17 build will use, all else being equal. That may be the case, and, for the major platforms, that may even be probable, but personally, I wouldn't bet the house on it for embedded platforms. But yeah, that's something that can be checked, and would probably¹ enable said use-case. Thanks, Marc ¹ I say "probably" because history shows that our wholesale exporting of non-polymorphic classes will find a way to break this in corner-cases, I'm sure. -- Marc Mutz <marc.m...@qt.io> Principal Software Engineer The Qt Company Erich-Thilo-Str. 10 12489 Berlin, Germany www.qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development