On Tue, 30 Jun 2015 12:06:46 +0200 Murray Cumming <murr...@murrayc.com> wrote:
> On Tue, 2015-06-30 at 10:53 +0100, Chris Vine wrote: > > On Tue, 30 Jun 2015 08:32:43 +0200 > > Murray Cumming <murr...@murrayc.com> wrote: > > > On Mon, 2015-06-29 at 19:44 +0100, Chris Vine wrote: > > > [snip] > > > > Fedora 23, which will use gcc-5.1 with the new ABI, will have to > > > > recompile all its C++ binaries (libraries and programs)[1], for > > > > all versions of C++ those libraries and programs may happen to > > > > use. > > > [snip] > > > > > > And would you agree that Ubuntu (for instance) will have to do the > > > same thing when C++11 (--std=c++11) becomes the default in g++ 6, > > > when they use g++ 6? > > > > No. Assuming gcc-6 still provides libstdc++ with both ABIs (my > > guess is that gcc will do so for a considerable number of > > releases), then it would depend on whether ubuntu chooses to use > > the new ABI instead of the old one for its C++ binaries. > > Isn't Ubuntu likely to make the same choice that Fedora has made, at > least at some point? > > Or is Fedora just doing this (using the C++11 libstdc++ API) because > they really like C++11 and want to make the C++11 experience as good > as possible? I would guess that it is because fedora is a fast moving distribution and they like to press ahead with what everyone will be doing in a few years' time. I doubt it is in order to be especially C++ friendly. The ABI changes are pretty much irrelevant to the average C++11/14 user. How often does your code's performance depend on O(1) rather than O(N) complexity of std::list::size() (and if this does affect performance in a particular case, why are you using lists in the first place)? And how often does your code rely on the requirement that non-const operator[]() for a string may not invalidate iterators into the string (C++03 does permit that, C++11 does not, and is what rules out copy-on-write)? For what it is worth, I write all my C++11 code with the old ABI, for the moment. Chris _______________________________________________ gtkmm-list mailing list gtkmm-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtkmm-list
