🚀 go-pugleaf

In article <4jevb1$kkp@engnews1.Eng.Sun.COM> clamage@Eng.sun.com (Steve Clamage) writes:

   From: clamage@Eng.sun.com (Steve Clamage)
   Newsgroups: comp.std.c++
   Date: 28 Mar 1996 21:16:23 GMT

   In article 96Mar27195129@trigati.cs.haverford.edu, davew@trigati.cs.haverford.edu (David G. Wonnacott) writes:
   >
   >I am looking for an explanation for the rationale behind the decision
   >of the standards committee to disallow the binding of a non-const
   >reference to an rvalue.

   The basic reason is that it usually is an error.
   ...

   Yes, there are times when you would like to be able to bind an rvalue
   to a non-const reference, since the only things you care about are
   sure to happen anyway.		...	       I believe the C++
   committee looked for ways to allow this binding of an rvalue to a non-const
   reference in cases where the results were what was intended, but failed to
   find a good way to define those cases.

What ever happened to "make it legal but recommend a warning?"  My
understanding of "illegal" is that the compiler should refuse to
compile the program.  I agree that the vast majority of occurances of
a non-const reference to an rvalue would be due to programmer errors.
But then again, so are many cases of "if (x=5) ...".

As I said, we make use of this all over the place, and its going to be
a real problem for us if this produces an error from most compilers.

We have a class for which (1) copying can be expensive, and (2) there
are some operations that extract information only after having a side
effect that can not be avoided (without copying).  Imagine if we could
do ++i but not i+1 for integers, and that copying them was expensive.
Suppose we we have a library that provides functions f1 and f2:

   int f1()         { ... }
   int f2(int &i)   { ++i; return i; }

(note that we copy the return values, but not the argument - it turns
out that we are more concerned with unnecessary copying for arguments
than return values).  The user of our library can then use y=f2(x),
and x will be incremented, and y will take on the new value.  We'd
like to let them use y=f2(f1()), to make y take on the value that is
one more than the value returned by f1().  The side-effect that was
performed on the object returned from f1 is lost, but we don't care.

I don't see any way of writing this without either (a) binding a
non-const reference to an rvalue, (b) forcing the user of our library
to set up an explicit temporary variable every time they use this
construct, or (c) giving up on avoiding this overhead and using call
by value for f2, or (d) doing something really brain-damaged like:

   int f2(const int &j) { int &i = (int &)j; i++; return i; }

But (a) is illegal, (b) is unreasonably inconvenient for our users,
(c) is inefficient, and (d) makes me queasy.

Dave W
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your 
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu 
]