Movatterモバイル変換

Proposed Resolution (10/99):

[Note: a small portion of this wording is superseded by theresolution ofissue 185.]

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 omitthe copy construction of a class object, even if the copy constructorand/or destructorfor the object have side effects. In such cases, the implementation treatsthe source and target of the omitted copy operation as simply two differentways of referring to the same object, and the destruction of that objectoccurs at the later of the times when the two objects would have been destroyedwithout the optimization [footnote: Because only one object is destroyedinstead of two, and one copy constructor is not executed, there is stillone object destroyed for each one constructed.end footnote].This elisionof copy operations is permitted in the following circumstances (which maybe combined to eliminate multiple copies):


• in a return statement in a function with a class return type, where theexpression is the name of a non-volatile automatic object with the samecv-unqualified type as the function return type, the copy operation canbe omitted by constructing the automatic object directly into the function'sreturn value

• when a temporary class object(6.8.7 [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 objectdirectly 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();

Issue 1

11.4.5.3 [class.copy.ctor](From J16/99-0005 = WG21 N1182, "Proposed Resolutions for CoreLanguage Issues 6, 14, 20, 40, and 89")

There are three related sub-issues in this issue, all dealing with theelision of copy constructors as described in11.4.5.3 [class.copy.ctor]paragraph 15:

1. The text should make clear that the requirement that the copy constructorbe accessible and unambiguous is not relaxed in cases where a call to acopy constructor is elided.
2. It is not clear from the text that the two optimizations described canbe applied transitively, and, if so, the implications for the order ofdestruction are not spelled out.
3. The text should exclude applying the function-return optimization if theexpression names a static or volatile local object.

After discussion in Santa Cruz, the core group decided that sub-issue#1 required no change; the necessity of an accessible and unambiguous copyconstructor is made clear in6.8.7 [class.temporary]paragraph 1 and need not be repeated in this text. The remaining two sub-issuesappear to be valid criticisms and should be addressed.