[Development] Raising the minimum to C++20

[Marc Mutz]

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.mutz at 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