C++ ABI Issues Pages
Daveed Vandevoorde
daveed at edg.com
Sat Jul 3 00:00:44 UTC 1999
At yesterday's meeting the issue of optimizing parameter copies came up,
and some of us recalled that the 1997 London meeting J16/WG21 had restricted
the scope of [class.copy] 12.8/15 (which deals with eliding calls to the
copy constructor).
I mentioned that at the 1999 Dublin meeting the issue had been raised
again and I was to dig up the relevant items from the Core Issues List.
The relevant items are 6 and (to a lesser extent) 20. I quote them
below.
Executive summary: unless a temporary is passed, the observable copy of
an object passed by value can not be elided.
Daveed
6. Should the optimization that allows a class object to alias another object also allow the
case of a parameter in an inline function to alias its argument?
Section: 12.8 class.copy Status: extension Submitter: unknown Date: unknown
(Previously numbered 876b.) (See also paper J16/99-0005 = WG21 N1182.)
At the London meeting, 12.8 class.copy paragraph 15 was changed to limit the optimization
described to only the following cases:
the source is a temporary object
the return value optimization
One other case was deemed desirable as well:
aliasing a parameter in an inline function call to the function call argument.
However, there are cases when this aliasing was deemed undesirable and, at the London
meeting, the committee was not able to clearly delimit which cases should be allowed and
which ones should be prohibited.
Can we find an appropriate description for the desired cases?
Rationale (04/99): The absence of this optimization does not constitute a defect in the
Standard, although the proposed resolution in the paper should be considered when the
Standard is revised.
20. Some clarifications needed for 12.8 para 15
Section: 12.8 class.copy Status: ready Submitter: unknown Date: unknown
(Previously numbered 931.)
Issue 1
12.8 class.copy (From J16/99-0005 = WG21 N1182, "Proposed Resolutions for Core Language
Issues 6, 14, 20, 40, and 89")
There are three related sub-issues in this issue, all dealing with the elision of copy
constructors as described in 12.8 class.copy paragraph 15:
1. The text should make clear that the requirement that the copy constructor be accessible
and unambiguous is not relaxed in cases where a call to a copy constructor is elided.
2. It is not clear from the text that the two optimizations described can be applied
transitively, and, if so, the implications for the order of destruction are not spelled
out.
3. The text should exclude applying the function-return optimization if the expression
names a static or volatile local object.
Analysis
After discussion in Santa Cruz, the core group decided that sub-issue #1 required no change;
the necessity of an accessible and unambiguous copy constructor is made clear in 12.2
class.temporary paragraph 1 and need not be repeated in this text. The remaining two sub-
issues appear to be valid criticisms and should be addressed.
Proposed Resolution (04/99): The paragraph in question should be rewritten as follows. In
addition, references to this section should be added to the index under "temporary,
elimination of," "elimination of temporary," and "copy, constructor elision."
When certain criteria are met, an implementation is allowed to omit copying a class
object, even if the copy constructor and/or destructor for the object have side
effects. In such cases, the implementation treats the source and target of the
omitted copy operation as simply two different ways of referring to the same object,
and the destruction of that object occurs at the later of the times when the two
objects would have been destroyed without the optimization [footnote: Because
only one object is destroyed instead of two, and one copy constructor is not
executed, there is still one object destroyed for each one constructed.
end footnote].
This elision of copy operations is permitted in the following circumstances (which
may be combined to eliminate multiple copies):
. in a return statement in a function with a class return type, where the
expression is the name of a non-volatile automatic object with the same
cv-unqualified type as the function return type, the copy operation can
be omitted by constructing the automatic object directly into the
function's return value
. when a temporary class object (12.2 class.temporary ) would be copied to
a class object with the same cv-unqualified type, the copy operation can
be omitted by constructing the temporary object directly into the target
of the omitted copy [Example:
class Thing {
public:
Thing();
~Thing();
Thing(const Thing&);
};
Thing f() {
Thing t;
return t;
}
Thing t2 = f();
Here the criteria for elision can be combined to eliminate two calls to
the copy constructor of class Thing: the copying of the local automatic
object t into the temporary object for the return value of function f()
and the copying of that temporary object into object t2. Effectively, the
construction of the local object t can be viewed as directly initializing
the global object t2, and that object's destruction will occur at program
exit. ---end example]
More information about the cxx-abi-dev
mailing list