This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of CD1 status.

### 402. wrong new expression in [some_]allocator::construct

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.