Re: [PATCH] C++ space optimization: de-cloning con/de/structors

[Mike Stump <mrs at apple dot com>]

On Wednesday, August 7, 2002, at 05:41 PM, Jason Merrill wrote:
> Similarly, in the case of the decloning thunks, the compiler is not 
> allowed
> to add new copy constructor calls.  So this is a correctness issue, not
> just an optimization.
Doesn't the latitude in:

  12.2  Temporary objects                              [class.temporary]

1 Temporaries  of class type are created in various contexts: binding an
  rvalue  to  a  reference   (_dcl.init.ref_),   returning   an   rvalue
  (_stmt.return_),  a  conversion  that  creates an rvalue (_conv.lval_,
  _expr.static.cast_,  _expr.const.cast_,  _expr.cast_),   throwing   an
  exception  (_except.throw_), entering a handler (_except.handle_), and
  in some initializations (_dcl.init_).  [Note: the lifetime  of  excep-
  tion objects is described in _except.throw_.  ] Even when the creation
  of the temporary object is avoided (_class.copy_),  all  the  semantic
  restrictions must be respected as if the temporary object was created.
  [Example: even if the copy constructor is not called, all the semantic
  restrictions,  such as accessibility (clause _class.access_), shall be
  satisfied.  ]

2 [Example:
  class X {
      // ...
  public:
      // ...
      X(int);
      X(const X&);
      ~X();
  };

  X f(X);
  void g()
  {
      X a(1);
      X b = f(X(2));
      a = f(a);
  }
  Here, an implementation might use a temporary in  which  to  construct
  X(2)  before  passing  it  to f() using X's copy-constructor; alterna-
  tively, X(2) might be constructed in the space used to hold the  argu-
  ment.

cover this case?  Or maybe the IS modified the wording to not allow the 
copy?