This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] C++ space optimization: de-cloning con/de/structors
- From: Mike Stump <mrs at apple dot com>
- To: Jason Merrill <jason at redhat dot com>
- Cc: Stuart Hastings <stuart at apple dot com>, gcc-patches at gcc dot gnu dot org
- Date: Wed, 7 Aug 2002 18:48:37 -0700
- Subject: Re: [PATCH] C++ space optimization: de-cloning con/de/structors
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?