Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
Which is really hard to argue against, since they then had to revert the change in the middle of a stable series!
Anyway, I guess the important thing is that they returned to sanity, although obviously it would have been better for that to happen before releasing 4.7.0.
Day: GNOME OS
Posted Aug 10, 2012 17:50 UTC (Fri) by slashdot (guest, #22014)
The gcc developers pretty much merely slavishly followed that idiocy without questioning, until they realized their mistake.
Posted Aug 10, 2012 18:30 UTC (Fri) by nix (subscriber, #2304)
This was just a new constraint, which was unfortunately incompatible with the existing implementation of the list<> in GCC, and it was impossible to change it without breaking backward compatibility. (One problem with templated data structures is that a lot of things you wouldn't expect to be ABI concerns actually are, because they are included in programs using them via template expansion.)
Deciding whether to violate the language standard or piss off your users is an unpleasant fork to be in -- but it's not the committee's fault either, because this sort of change is what language standard revisions have always done. C99 broke some valid C89 code: C11 breaks some more. It's just that the set of GCC-compiled code that got broken by a fully conformant implementation of the C++11 list<> was rather large...
Posted Aug 10, 2012 19:13 UTC (Fri) by slashdot (guest, #22014)
And that's the problem.
Adding the new constraint by the C++ committee was simply asinine, especially, since you lose O(1) list splicing (and you can keep the size yourself with C++98 std::list, but can't do O(1) splice yourself with C++11 std::list), and because at least one existing implementation could not provide it while keeping compatibility.
They should have added a new type if they wanted C++ to have a linked list with O(1) size().
BTW, they also broke multithreaded programs using std::list, since unless the size field is updated with atomics (which kills performance on several archs), it's no longer true that you can add to the head of a non-empty list in a thread and to the tail in another thread, which would work in C++98 libstdc++.
As for the GCC, I think it should need a separate option to enable ABI-breaking C++11 changes, and --std=c++11 should only enable the backwards compatible C++11 subset, which appears to be what they hint at in the recent announcement.
C++11 is not fully implemented anyway, so that's not an issue for now, and perhaps in the meantime the standard can be revised to revert the changes.
Posted Aug 10, 2012 19:28 UTC (Fri) by juliank (subscriber, #45896)
Posted Aug 10, 2012 19:42 UTC (Fri) by juliank (subscriber, #45896)
Posted Aug 10, 2012 20:02 UTC (Fri) by foom (subscriber, #14868)
The change was a mistake, the defense of it was wrong. That STILL doesn't mean you get to call the people involved idiots.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds