This is the mail archive of the
mailing list for the GCC project.
Re: [patch] Use abi_tag attribute on std::list
- From: Jonathan Wakely <jwakely at redhat dot com>
- To: libstdc++ at gcc dot gnu dot org
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Fri, 3 Oct 2014 15:49:55 +0100
- Subject: Re: [patch] Use abi_tag attribute on std::list
- Authentication-results: sourceware.org; auth=none
- References: <20141003130447 dot GD4197 at redhat dot com> <alpine dot DEB dot 2 dot 11 dot 1410031600040 dot 1565 at laptop-mg dot saclay dot inria dot fr>
On 03/10/14 16:25 +0200, Marc Glisse wrote:
On Fri, 3 Oct 2014, Jonathan Wakely wrote:
This is the patch I intend to commit to make std::list::size() O(1) as
required by C++11.
This is an ABI change, so std::list will get tagged with
abi_tag("cxx11") so that it mangles differently.
Assuming a future where we have both _GLIBCXX_ABI_TAG_CXX11 and
_GLIBCXX_ABI_TAG_CXX17, I don't really see how
is supposed to work. We don't want to define _GLIBCXX_DEFAULT_ABI_TAG
to _GLIBCXX_ABI_TAG_CXX17 and suddenly have std::list change mangling.
Should it be called _GLIBCXX_DEFAULT_ABI_TAG_CXX11, meaning
I suppose so ... or _GLIBCXX_MAYBE_ABI_TAG_CXX11 ?
Defining a dummy _M_distance in the old abi case is a bit strange (we
could protect the single use with #if _GLIBCXX_USE_CXX11_ABI), but why
Yeah, I was trying to minimise the preprocessor conditionals, but
maybe that's one step too far.
Do you mind if I move (in a future patch once yours is committed)
_M_size into _M_impl::_M_node as suggested in PR 61347?
Gah, that's where I had it until earlier this week, and I looked at it
and wondered why it was in the _List_impl class (because you only need
one member in there to benefit from the empty base-class
I will move it back there, since I already have that code on another
branch, so there's no point making you change the code to match
something I've already got!
Thanks for your useful comments (as always).