At some point in the "what is a reference?" wars, somebody wrote:

| : Correct.  You're interpretation corresponds to mine, however...  The
| : lifetime of an object depends on whether it has a non-trivial
| : constructor or not.  Do references have a non-trivial constructor?

The lifetime of an object now depends on more than whether it has a
non-trivial constructor.  It also depends on whether the object in question
is involved in one or more applications of what was originally the return
value optimizaion (ARM 12.1.1c).  From section 12.8 of the September 1996
DWP:

15Whenever a class object is copied and the original object and the copy
  have the same type, if the implementation can prove  that  either  the
  original  object  or  the  copy will never again be used except as the
  result of an implicit destructor call (_class.dtor_),  an  implementa-
  tion  is permitted to treat the original and the copy as two different
  ways of referring to the same object and not perform a  copy  at  all.
  In  that  case, the object is destroyed at the later of times when the
  original  and  the  copy  would  have  been  destroyed   without   the
  optimization.7) [Example:
          class Thing {
          public:
                  Thing();
                  ~Thing();
                  Thing(const Thing&);
                  Thing operator=(const Thing&);
                  void fun();
          };
          void f(Thing t) { }
          void g(Thing t) { t.fun(); }

          int main()
          {
                  Thing t1, t2, t3;
                  f(t1);
                  g(t2);
                  g(t3);
                  t3.fun();
          }
  Here  t1  does not need to be copied when calling f because f does not
  use its formal parameter again after copying it. Although g  uses  its
  parameter,  the  call  to g(t2) does not need to copy t2 because t2 is
  not used again after it is passed to g.  On the other hand, t3 is used
  after passing it to g so calling g(t3) is required to copy t3.  ]

  _________________________
  7)  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.

Scott

--
Scott Meyers, Ph.D.                  Voice: 503/638-6028
C++ Consulting and Training          Fax:   503/638-6614
Author of "Effective C++"            Email: smeyers@netcom.com
  and "More Effective C++"           WWW:   http://www.teleport.com/~smeyers
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Scott Meyers <smeyers@teleport.com> wrote:
[...]
: From section 12.8 of the September 1996 DWP:

: 15Whenever a class object is copied and the original object and the copy
:   have the same type, if the implementation can prove  that  either  the
:   original  object  or  the  copy will never again be used except as the
:   result of an implicit destructor call (_class.dtor_),  an  implementa-
:   tion  is permitted to treat the original and the copy as two different
:   ways of referring to the same object and not perform a  copy  at  all.
[...]

Did this rule introduce something new, or was it already a consequence of
the as-if rule?

Tom Payne
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Tom Payne writes:

> Scott Meyers <smeyers@teleport.com> wrote:
> [...]
> : From section 12.8 of the September 1996 DWP:

> : 15Whenever a class object is copied and the original object and the copy
> :   have the same type, if the implementation can prove  that  either  the
> :   original  object  or  the  copy will never again be used except as the
> :   result of an implicit destructor call (_class.dtor_),  an  implementa-
> :   tion  is permitted to treat the original and the copy as two different
> :   ways of referring to the same object and not perform a  copy  at  all.
> [...]

> Did this rule introduce something new, or was it already a consequence of
> the as-if rule?

If either the copy-constructor or the destructor could generate any
side-effect, such as sending something to cout, writing to a file,
etc, this would not follow the as-if rule, but the compiler is allowed
to optimize away the copy.

--
Alexandre Oliva
mailto:oliva@dcc.unicamp.br
Universidade Estadual de Campinas, SP, Brasil
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Tom Payne <thp@cs.ucr.edu> writes:

]Scott Meyers <smeyers@teleport.com> wrote:
][...]
]: From section 12.8 of the September 1996 DWP:
]
]: 15Whenever a class object is copied and the original object and the copy
]:   have the same type, if the implementation can prove  that  either  the
]:   original  object  or  the  copy will never again be used except as the
]:   result of an implicit destructor call (_class.dtor_),  an  implementa-
]:   tion  is permitted to treat the original and the copy as two different
]:   ways of referring to the same object and not perform a  copy  at  all.
][...]
]
]Did this rule introduce something new, or was it already a consequence of
]the as-if rule?

It introduced something new.  A conforming program can detect whether this
optimization has been performed by comparing object addresses, or by
using side-effects in the copy-constructor, etc., so this optimization
would not be allowed as a consequence of the as-if rule.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Tom Payne wrote:
>
> Scott Meyers <smeyers@teleport.com> wrote:
> [...]
> : From section 12.8 of the September 1996 DWP:
>
> : 15Whenever a class object is copied and the original object and the copy
> :   have the same type, if the implementation can prove  that  either  the
> :   original  object  or  the  copy will never again be used except as the
> :   result of an implicit destructor call (_class.dtor_),  an  implementa-
> :   tion  is permitted to treat the original and the copy as two different
> :   ways of referring to the same object and not perform a  copy  at  all.
> [...]
>
> Did this rule introduce something new, or was it already a consequence of
> the as-if rule?

No, it's new; some optimisations cannot be done under the as-if rule,
for example the call of a ctor (except when its code is available
inline).

It's easy to check if your compiler does what I call 'C++ level
optimisations' (opposed to C level); I use my Viewer class:

class Viewer
{
    public:
        Viewer()
        { cout << "Viewer::Viewer () @ " << this << "\n"; }

        Viewer(const Viewer& rhs)
        { cout << "Viewer::Viewer(const Viewer&) @ " << this << " from "
  << &rhs << "\n"; }

        void operator=(const Viewer& rhs)
        { cout << "Viewer::operator=(const Viewer&) @ " << this << " from "
  << &rhs << "\n"; }

        ~Viewer()
        { cout << "Viewer::~Viewer () @ " << this << "\n"; }
};

--

Valentin Bonnard
mailto:bonnardv@pratique.fr
http://www.pratique.fr/~bonnardv (Informations sur le C++ en Francais)
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]