This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of NAD status.
Section: 220.127.116.11 [allocator.traits.types] Status: NAD Submitter: Pete Becker Opened: 2010-02-11 Last modified: 2016-01-28
Priority: Not Prioritized
View all other issues in [allocator.traits.types].
View all issues with NAD status.
Duplicate of: 1375
says that containers should have a nested typedef that defines their
value_type&; the previous
standard deferred to the allocator to define its
reference_type, and containers simply passed the allocator's
typedef on. This change is a mistake. Allocators should define both a
pointer type and a
reference type. That's essential
for their original purpose, which was to make different memory models
transparent. If an allocator defines a
pointer type that isn't
compatible with a normal pointer it also has to define a corresponding
reference type. For example (and please forgive a Windows-ism),
if an allocator's pointer is
T __far*, then it's
reference has to be
T __far&. Otherwise everything
crashes (under the hood, references are pointers and have to have the
same memory access mechanics). Extensions such as this for more general
memory models were explicitly encouraged by C++03, and the allocator's
reference typedefs were the hooks for such
extensions. Removing the allocator's
const_reference typedefs makes those extensions unimplementable
and breaks existing implementations that rely on those hooks.
[ 2010-02-25 Alisdair adds: ]
vector<bool>::referenceis a nested class, and not a typedef. It should be removed from the list of containers when this change is made.
In general, I am uncomfortable placing this reference requirement on each container, as I would prefer to require:is_same<Container::reference, Container::iterator::reference>
This distinction is important, if we intend to support proxy iterators. The iterator paper in the pre-Pittsburgh mailing (N3046) does not make this proposal, but organises clause 24 in such a way this will be much easier to specify.
The changes to clause 20 remain important for all the reasons Pete highlights.
[ 2010 Batavia ]
vector from list of templates that should be adjusted as of meeting outcome.
[ 2010 post-Batavia ]
vector<bool> reference by
vector reference because of misinterpreting meeting typo.
Additional corrected numbering in P/R to N3225 wording.
[ 2010-12-06 Daniel reopens ]
Unfortunately, the current P/R is defective for several reasons:
T&, namely in:
Especially the second and third items are misses in the 1318 P/R, e.g. in N2723 or in C++03 these were referring to
a value of type
a value of type
T&obtained by the expression
a value of type
const T&obtained by the expression
*qor by conversion from a value
None of them is referenced anywhere in the allocator requirements
s where historically needed to
define the expressions
a.address(s) which are gone now,
t was needed to define the expression
a.construct(p, t) which has been
The easiest fix seems to be to remove all three rows from Table 43.
similar to the other container types, i.e. to definestack priority_queue queue
const_reference now as
This would not only be an ill-formed definition (because there is no nametypedef typename allocator_traits<Allocator>::reference reference; typedef typename allocator_traits<Allocator>::const_reference const_reference;
Allocator in scope), but it would also introduce a breakage compared to C++03,
where these definitions where already referring to the definition of the wrapped
containers. So, the adaptor class templates should be removed from the current list.
match_result::reference is currently defined as
because it is an immutable container (And we had this definition already in N2723). The application of the rule would change this silently.typedef const_reference reference;
unordered_ containers is incomplete.
The reason is a current inconsistency between these containers and the rest: While
normally the definition of the pointer types is
for the unordered containers they aretypedef typename allocator_traits<Allocator>::pointer pointer; typedef typename allocator_traits<Allocator>::const_pointer const_pointer;
These definitions are not equivalent, because allocators are no longer required to define typedefstypedef typename allocator_type::pointer pointer; typedef typename allocator_type::const_pointer const_pointer;
allocator_traits were invented as a further indirection to cope
with that. I.e. for the unordered containers we need to bring both the definition
of references and pointers in sync.
[ 2011-02-23 Daniel updates the proposed wording with support from Pablo ]
The update attempts to fix the backward-compatibility problem that we have
introduced by ignoring the C++03 member function overloads
of allocator types in C++0x completely. The resolution attempts to fix that
by adding these functions as optional members of allocators that are considered
first before falling back to
pointer_traits::pointer_to. This still
allows us to remove the unused symbol
t from the table, but we adapt
s to purely refer to the typenames
[2011-03-06 Daniel adapts numbering to N3242]
[2011-03-11 Daniel removes
noexcept specifiers from
[2011-03-12 Further wording improvements by Daniel and Pablo]
Closed as NAD, no consensus to make a change
No consensus to make a change