Section: 16.4.4.6 [allocator.requirements] Status: CD1 Submitter: Markus Mauhart Opened: 2003-02-27 Last modified: 2016-01-28
Priority: Not Prioritized
View other active issues in [allocator.requirements].
View all other issues in [allocator.requirements].
View all issues with CD1 status.
Discussion:
I think that in par2 of [default.con.req] the last two lines of table 32 contain two incorrect type casts. The lines are ...
a.construct(p,t) Effect: new((void*)p) T(t) a.destroy(p) Effect: ((T*)p)?->~T()
.... with the prerequisits coming from the preceding two paragraphs, especially from table 31:
alloc<T> a ;// an allocator for T
alloc<T>::pointer p ;// random access iterator
// (may be different from T*)
alloc<T>::reference r = *p;// T&
T const& t ;
For that two type casts ("(void*)p" and "(T*)p") to be well-formed this would require then conversions to T* and void* for all alloc<T>::pointer, so it would implicitely introduce extra requirements for alloc<T>::pointer, additionally to the only current requirement (being a random access iterator).
Proposed resolution:
Accept proposed wording from N2436 part 1.
Note: Actually I would prefer to replace "((T*)p)?->dtor_name" with "p?->dtor_name", but AFAICS this is not possible cause of an omission in 12.4.6 [over.ref] (for which I have filed another DR on 29.11.2002).
[Kona: The LWG thinks this is somewhere on the border between
Open and NAD. The intend is clear: construct constructs an
object at the location p. It's reading too much into the
description to think that literally calling new is
required. Tweaking this description is low priority until we can do
a thorough review of allocators, and, in particular, allocators with
non-default pointer types.]
[ Batavia: Proposed resolution changed to less code and more description. ]
[ post Oxford: This would be rendered NAD Editorial by acceptance of N2257. ]
[ Kona (2007): The LWG adopted the proposed resolution of N2387 for this issue which was subsequently split out into a separate paper N2436 for the purposes of voting. The resolution in N2436 addresses this issue. The LWG voted to accelerate this issue to Ready status to be voted into the WP at Kona. ]