This page is a snapshot from the LWG issues list, see theLibrary Active Issues List for more information and the meaning ofCD1 status.
Section: 16.4.4.6[allocator.requirements], 20.2.10.2[allocator.members]Status:CD1Submitter: Markus MauhartOpened: 2003-02-27Last modified: 2016-01-28
Priority:Not Prioritized
View otheractive issues in [allocator.requirements].
View all otherissues in [allocator.requirements].
View all issues withCD1 status.
Discussion:
This applies to the new expression that is contained in both par12 of20.2.10.2[allocator.members] and in par2 (table 32) of [default.con.req].I think this new expression is wrong, involving unintended sideeffects.
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 moststd::container<T,every_alloc<T>> use it; a workaroundwould be adding placement new and delete functions with adequatesignature and semantic to class T, but class T might come from anotherparty. Maybe even worse is the case when T has placement new anddelete functions with adequate signature but with "unknown" semantic:I dont like to speculate about it, but whoever implementsany_container<T,any_alloc> and wants to use construct(..)probably must think about it.
Proposed resolution:
Replace "new" with "::new" in both cases.