[Moderator's note: this defect report has been
 forwarded to the C++ committee. -moderator.]

This applies to the new expression that is contained in both par12
of 20.4.1.1 [lib.allocator.members] and in par2 (table 32) of
20.1.5 [lib.allocator.requirements].
I think this new expression is wrong, involving unintended side effects.

[lib.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)


[lib.allocator.requirements] 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.

Therefore I think that "new" should be replaced with "::new" in both cases.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]