6 ms·
To be fair to the committee, upgrading C++ compilers is already a chore, even with the changes as small as they are. Would you rather spend time updating your l
by abbefaria27 29d ago
To be fair to the committee, upgrading C++ compilers is already a chore, even with the changes as small as they are. Would you rather spend time updating your lambdas because they changed how capture works (a real breakage not long ago), or doing something of actual value? The only reason we finally updated from Python 2.7 to 3 was that the OS vendors dropped it, but it was effectively a waste of time.
That aside, I don’t understand why ABI breakage is a big deal. There’s probably a good reason, but ABIs are already so fragile, you can’t mix and match different compiler versions anyway, or even the same compiler with different flags. Why does it matter if setting -std29 or whatever breaks ABI when -fno-rtti does the same?
The C++ committee should really stop adding esoteric features for library writers and focus on stuff for normies. Tooling is one as the article says, or how about finally getting Networking TS? This is probably the only mainstream language left that doesn’t have even basic networking support.
- neutronicus 29d agoThe application I work on has an extension API that only requires C++11, but we compile against all the same headers in C++20. Obviously we need ABI compatibility between the two standards for this to work.
- aw1621107 29d ago> Why does it matter if setting -std29 or whatever breaks ABI when -fno-rtti does the same? I think it's the distinction between can and must. Right now you can preserve ABI across compiler versions if you want to (and that is indeed a desirable quality for some users). The pushback is against changes to the standard that would require an ABI break.