| |||||||||||||
Day: GNOME OSDay: GNOME OSPosted Aug 10, 2012 19:13 UTC (Fri) by slashdot (guest, #22014)In reply to: Day: GNOME OS by nix Parent article: Day: GNOME OS
> 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
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.
(Log in to post comments)
Day: GNOME OS Posted Aug 10, 2012 19:28 UTC (Fri) by juliank (subscriber, #45896) [Link]
If I had to guess, I'd say that the O(1) size() thing was introduced to the standard by Microsoft.
Day: GNOME OS Posted Aug 10, 2012 19:42 UTC (Fri) by juliank (subscriber, #45896) [Link]
OK, it seems to be pushed by Apple via proxy, not Microsoft, as far as I can tell.
|
|||||||||||||