[Bug libstdc++/64135] Allocator base classes should use reserved names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64135 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |12.0 --- Comment #4 from Jonathan Wakely --- Fixed for GCC 12, not suitable for backports.
[Bug libstdc++/64135] Allocator base classes should use reserved names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64135 --- Comment #3 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:fe9571a35db53e5203326f854f73e432691d67f6 commit r12-5873-gfe9571a35db53e5203326f854f73e432691d67f6 Author: Jonathan Wakely Date: Wed Dec 1 17:56:23 2021 + libstdc++: Fix non-reserved name in std::allocator base class [PR64135] The possible base classes of std::allocator are new_allocator and malloc_allocator, which both cause a non-reserved name to be declared in every program that includes the definition of std::allocator. This is non-conforming. This change replaces __gnu_cxx::new_allocator with std::__new_allocator which is identical except for using a reserved name. The non-standard extension __gnu_cxx::new_allocator is preserved as a thin wrapper over std::__new_allocator. There is no problem with the extension using a non-reserved name now that it's not included by default in other headers. The same change could be done to __gnu_cxx::malloc_allocator but as it's not the default configuration it can wait. libstdc++-v3/ChangeLog: PR libstdc++/64135 * config/allocator/new_allocator_base.h: Include instead of . (__allocator_base): Use std::__new_allocator instead of __gnu_cxx::new_allocator. * doc/xml/manual/allocator.xml: Document new default base class for std::allocator. * doc/xml/manual/evolution.xml: Likewise. * doc/html/*: Regenerate. * include/Makefile.am: Add bits/new_allocator.h. * include/Makefile.in: Regenerate. * include/experimental/memory_resource (new_delete_resource): Use std::__new_allocator instead of __gnu_cxx::new_allocator. * include/ext/new_allocator.h (new_allocator): Derive from std::__new_allocator. Move implementation to ... * include/bits/new_allocator.h: New file. * testsuite/20_util/allocator/64135.cc: New test.
[Bug libstdc++/64135] Allocator base classes should use reserved names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64135
--- Comment #2 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #1)
> Another option would be to drop the base class from std::allocator when
> configured to derive from new_allocator, and just inline that code into
> std::allocator. That's an ABI break, because it would no longer have a base
> class of type __gnu_cxx::new_allocator, but maybe it's one that wouldn't
> cause any problems in practice.
I think we can mitigate the ABI break by giving __gnu_cxx::new_allocator and
std::allocator a common base class, which would still prevent them from being
potentially-overlapping subobjects as is the case today.
Testcase for the current ABI properties:
#include
#include
struct A : __gnu_cxx::new_allocator { };
struct B : std::allocator, A { };
struct C : std::allocator { A a; };
static_assert( sizeof(B) == 2 );
static_assert( sizeof(C) == 2 );
[Bug libstdc++/64135] Allocator base classes should use reserved names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64135 --- Comment #1 from Jonathan Wakely --- One option would be to just rename the base class (possibly only the default new_allocator one, as selecting a different allocator implementation is an explicit choice, and so users can deal with the consequences). Another option would be to drop the base class from std::allocator when configured to derive from new_allocator, and just inline that code into std::allocator. That's an ABI break, because it would no longer have a base class of type __gnu_cxx::new_allocator, but maybe it's one that wouldn't cause any problems in practice.
[Bug libstdc++/64135] Allocator base classes should use reserved names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64135 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-02-20 Ever confirmed|0 |1
