This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: C++ ABI RFC [was Re: C++/libiberty PATCH for many mangling fixes (6057, 48051, 50855, 51322, etc)]
- From: Benjamin Kosnik <bkoz at redhat dot com>
- To: Jonathan Wakely <jwakely dot gcc at gmail dot com>
- Cc: Jason Merrill <jason at redhat dot com>, gcc at gcc dot gnu dot org, libstdc++ at gcc dot gnu dot org
- Date: Fri, 13 Jan 2012 09:40:10 -0800
- Subject: Re: C++ ABI RFC [was Re: C++/libiberty PATCH for many mangling fixes (6057, 48051, 50855, 51322, etc)]
- References: <4F0769D4.2070802@redhat.com> <4F0C4BB7.1090009@redhat.com> <20120112111646.42c5fc0c@shotwell> <CAH6eHdT9H=wi8bCVuWazan_ip5N6XF_5ZXGPbB3cJWQo3AeVGg@mail.gmail.com>
> I like the idea, but not very strongly. I can live with having to say
> -std=c++11 (which I do via shell functions or scripts)
Well, the actual C++11 compile/runtime environment is going to be more
than just -std=c++11. It's looking something like -std=c++11
-fabi-version=7 + versioned namespaces + other container changes.
That's why I'd like to have a configure option.
> My completely unfounded prediction is that many G++ users will move to
> C++11 a lot quicker than the C community moved to C99.
Here's hoping!
> As an aside, how do you feel about starting to make those ABI breaking
> changes in the __7 versioned namespace? There are changes we know we
> need to make for C++11 conformance, but can't without breaking the
> ABI. If users explicitly select an incompatible ABI via the versioned
> namespace and .so.7 then there's no reason not to give them the best
> possible C++11 support we can, right?
You seem to have answered this in follow-up email. Note that versioned
namespaces impact C++03 and C++11 std components, so switching just for
C++11 is a non-starter. So, we might as well just do this all at once...
-benjamin