| |||||||||||||
Day: GNOME OSDay: GNOME OSPosted Aug 8, 2012 20:16 UTC (Wed) by nix (subscriber, #2304)In reply to: Day: GNOME OS by juliank Parent article: Day: GNOME OS
* Fragile ABI. libstdc++ ABI is partially different when using -std=c++11, so combining C++11 code bases with older code bases is fragile.Jonathan Wakely pointed out recently that this is not true as of G++ 4.8: this has been backported to GCC 4.7.2+ as well (making 4.7.1's C++11 ABI incompatible with 4.7.2's, but anyone expecting a stable C++11 in GCC 4.7, the first version to have C++11 support at all, is living in a fantasy world in my opinion).
(Log in to post comments)
Day: GNOME OS Posted Aug 9, 2012 15:22 UTC (Thu) by arafel (subscriber, #18557) [Link]
Maybe. I'm not convinced it's an unrealistic desire to retain compatibility across minor version changes, personally - if you're breaking the ABI then don't call it 4.7.x.
But I try hard not to use C++, so from a personal point of view it doesn't affect me that much. ;-)
Day: GNOME OS Posted Aug 9, 2012 19:45 UTC (Thu) by mathstuf (subscriber, #69389) [Link]
Since a minor version bump is more likely to be done in a "stable" distro, fixing 4.7 so that it's compatible with other version series is likely better than keeping 4.7.x incompatible forever. Of course, this only matters when -std=c++11 is in effect, so the problem is unlikely to manifest unless 4.7.1 is the last release in some popular EL distro.
Day: GNOME OS Posted Aug 10, 2012 15:22 UTC (Fri) by slashdot (guest, #22014) [Link]
Wow, awesome.
Thank god that there are still some sane people in this world.
When some idiot from GCC announced that they wouldn't even try to keep a compatible ABI, I thought the GNOME3 disease had taken hold over there too, and all hope was lost, and it's great to hear the outbreak has instead been contained.
I mean, being able to compile any subset of a C++98 program as C++11 is an absolutely essential feature for obvious reasons, and not being able to use, say, foreach or auto without changing a program's ABI would be totally insane.
Day: GNOME OS Posted Aug 10, 2012 15:44 UTC (Fri) by mathstuf (subscriber, #69389) [Link]
The standard actually changed the ABI for std::string and std::list (possibly some others). The fix involves adding an attribute to help choose between the new and old ABI versions of classes. I can't find the blog link I read that on right now though.
From [1]:
> GCC versions 4.7.0 and 4.7.1 had changes to the C++ standard library which affected the ABI in C++11 mode: a data member was added to std::list changing its size and altering the definitions of some member functions, and std::pair's move constructor was non-trivial which altered the calling convention for functions with std::pair arguments or return types. The ABI incompatibilities have been fixed for GCC version 4.7.2 but as a result C++11 code compiled with GCC 4.7.0 or 4.7.1 may be incompatible with C++11 code compiled with different GCC versions and with C++98/C++03 code compiled with any version.
Day: GNOME OS Posted Aug 10, 2012 15:58 UTC (Fri) by jwakely (subscriber, #60262) [Link]
> The standard actually changed the ABI
No. The standard doesn't mention an ABI.
Some implementations' std::string and std::list have always been compatible with the new requirements, so don't have to change.
So more accurately, the C++11 standard requires certain properties of std::string and std::list which are incompatible with GCC's existing implementations of those types.
> I can't find the blog link I read that on right now though.
Maybe you mean my comment that nix refers to in the grandparent post?
Day: GNOME OS Posted Aug 10, 2012 16:08 UTC (Fri) by mathstuf (subscriber, #69389) [Link]
Ah, that makes more sense.
And yes, that blog post. Thanks :) .
Day: GNOME OS Posted Aug 10, 2012 16:01 UTC (Fri) by jwakely (subscriber, #60262) [Link]
There was never a question of foreach or auto changing the ABI, the incompatibilities are restricted to the library. Try to understand the facts before spouting rubbish and calling people idiots.
That idiot might be the same person who reported the news you applaud now. You're welcome by the way. Now when are you going to do something for me in return other than lower the level of discourse on LWN?
Day: GNOME OS Posted Aug 10, 2012 17:02 UTC (Fri) by slashdot (guest, #22014) [Link]
Except that I'm pretty sure auto or foreach required --std=c++11 to be used, which also resulted in some macros getting defined (__GXX0X_EXPERIMENTAL__ or something like that), which in turn changed the size of std::list in the STL headers due to an #ifdef.
As far as I can tell, this is what they fixed in GCC 4.7.2 (apparently by reverting the changes, with a plan to make it a separate switch along with the ability of C++98 and C++11 ABIs to coexist), and the rubbish is the one you just spouted.
I'm not sure who the "idiot" was, but I remember reading in GCC bugzilla someone who argued that the situation described above was totally fine, while any reasonable person would instead think that it had to be avoided at any cost, as they fortunately did later.
Obviously someone who does that definitely deserves to be insulted, since he first insulted and damaged all its users with such a decision.
Day: GNOME OS Posted Aug 10, 2012 17:25 UTC (Fri) by nix (subscriber, #2304) [Link]
Sheesh. You just don't take a hint, do you? The implementors of all this stuff - the mysterious impersonal 'they' you refer to -- are Paolo Carlini and Jon Wakely (y'know, the guy you're responding to). Neither of them are any sort of idiot, though I suspect from your failure to notice the authorship of these patches despite having received multiple direct links to them that *you* might need a major upgrade of your observational skill.
Day: GNOME OS Posted Aug 10, 2012 17:38 UTC (Fri) by slashdot (guest, #22014) [Link]
Well, definitely they were idiots when they introduced the ABI change in question and defended it on Bugzilla etc.
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) [Link]
BTW, the REAL idiots here are the guys in the C++ comittee who released a broken unimplementable standard (or alternatively, a standard without a full compatibility goal, which is even worse), despite having had 13 (!!!) years to fix it.
The gcc developers pretty much merely slavishly followed that idiocy without questioning, until they realized their mistake.
Day: GNOME OS Posted Aug 10, 2012 18:30 UTC (Fri) by nix (subscriber, #2304) [Link]
Er, you do realise that the C++ Standard, following the original STL, has imposed time and space complexity constraints on various parts of the library for a very long time? They're essential, because those constraints are the only difference between some of the Standard's data structures.
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...
Day: GNOME OS Posted Aug 10, 2012 19:13 UTC (Fri) by slashdot (guest, #22014) [Link]
> 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.
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.
Day: GNOME OS Posted Aug 10, 2012 20:02 UTC (Fri) by foom (subscriber, #14868) [Link]
Slashdot: You've been told more than once to stop with such insulting. It is exceedingly inappropriate. Maybe it's expected behavior on your namesake website, but not here.
The change was a mistake, the defense of it was wrong. That STILL doesn't mean you get to call the people involved idiots.
Day: GNOME OS Posted Aug 10, 2012 17:30 UTC (Fri) by ris (editor, #5) [Link]
> Obviously someone who does that definitely deserves to be insulted, since > he first insulted and damaged all its users with such a decision.
It is not at all obivious that anyone needs to be insulted just because they do something you disagree with. Please refrain from insulting people on this site. This is your second warning.
Day: GNOME OS Posted Aug 10, 2012 17:21 UTC (Fri) by nix (subscriber, #2304) [Link]
I do wonder if there's anyone on Earth slashdot won't call an idiot or a moron. There certainly doesn't seem to be any need for actual evidence before accusations are launched.
Day: GNOME OS Posted Aug 13, 2012 11:33 UTC (Mon) by nye (guest, #51576) [Link]
>I do wonder if there's anyone on Earth slashdot won't call an idiot or a moron. There certainly doesn't seem to be any need for actual evidence before accusations are launched.
But it's the open source way, and is widely (though not universally) supported here whenever the question comes up of whether this is an appropriate way to behave.
Standards are great, double standards doubly so.
(BTW I'm not being flippant - this is exactly the standard of behaviour that's considered normal and expected in the open source communities I look at. Compared to debian-devel it's positively gentlemanly.)
Day: GNOME OS Posted Aug 13, 2012 16:39 UTC (Mon) by apoelstra (subscriber, #75205) [Link]
> But it's the open source way, and is widely (though not universally) supported here whenever the question comes up of whether this is an appropriate way to behave.
I'm sure you could find many examples of open-source communities where rudeness and flamefests are considered appropriate behaviour. You could also find examples where the opposite is true.
But however "widely supported" this attitude is in the greater open source world, it is my experience that it's not supported here on LWN, which is (for the most part) a very polite, civil, intelligent place for discussion.
|
|||||||||||||