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