Section: 16.4.4.6 [allocator.requirements], 20.2.10.2 [allocator.members] 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:
This applies to the new expression that is contained in both par12 of 20.2.10.2 [allocator.members] and in par2 (table 32) of [default.con.req]. I think this new expression is wrong, involving unintended side effects.
20.2.10.2 [allocator.members] contains the following 3 lines:
11 Returns: the largest value N for which the call allocate(N,0) might succeed.
void construct(pointer p, const_reference val);
12 Returns: new((void *) p) T( val)
[default.con.req] in table 32 has the following line:
a.construct(p,t) Effect: new((void*)p) T(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 ;
Cause of using "new" but not "::new", any existing "T::operator new" function will hide the global placement new function. When there is no "T::operator new" with adequate signature, every_alloc<T>::construct(..) is ill-formed, and most std::container<T,every_alloc<T>> use it; a workaround would be adding placement new and delete functions with adequate signature and semantic to class T, but class T might come from another party. Maybe even worse is the case when T has placement new and delete functions with adequate signature but with "unknown" semantic: I dont like to speculate about it, but whoever implements any_container<T,any_alloc> and wants to use construct(..) probably must think about it.
Proposed resolution:
Replace "new" with "::new" in both cases.