🚀 go-pugleaf

On comp.lang.c++ (subject: How to tell if object was created with "new"),
one responder wrote the following ('A' is a class):

...
>   For example, with the following code...
>
>      A* pa1;
>      A* pa2;
>
>      if ((pa1 = new A()) && (pa2 = new A()))
>	  {
>	  // ...
>	  }
>
>
>   ...it is legal for a comiler to generate code that FIRST executes
>   both calls the operator new() and THEN calls the constructors.
...

Maybe this wasn't the best example, because of the logical AND, but its
point is that not in all cases can it be guaranteed that the constructor
will be called immediately after operator new (assuming that operator new
succeeds).

Section 5.3.4 of the WP states:

"9 Storage  for  the  object created by a new-expression is obtained from
  the appropriate allocation function. ..."

As this is in the section describing the syntax and execution of a
new-expression, it appears to me that storage allocation is part of the
execution of new-expression, and therefore that the constructor call
always follows the allocation, but is it possible that the following
from section 5 allows it to implementation-dependent? :

"4 ...  Except  where noted, the order of evaluation of operands of
individual operators and subexpressions of individual expressions, and the
order in which side effects take place, is unspecified. ..."

It seems to me that a compiler might be creating problems for itself
by allocating space for two objects before constructing the first (e.g.,
in handling an exception thrown by the first constructor or the second
operator new) and I don't know what benefits there could be in it. Maybe
no compiler would do it, but we still need to know if they are allowed to.

Being unfamiliar with how technically a standard should be interpreted,
I'm wondering if the WP is clear enough on this subject.

David White
davidw@werple.mira.net.au

[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]