🚀 go-pugleaf

In article <4jevb1$kkp@engnews1.Eng.Sun.COM>, clamage@Eng.sun.com (Steve
Clamage) writes:
> 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.

SNIP



> 
> 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. For example, given a class T:
> 	T f1();     // f1 returns a T rvalue
> 	f1().foo(); // ok only if foo is a const member function of T
> Sometimes you don't care about the effects of foo on the object here,
> and you only want the external side-effects of foo. 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 about the following rule

class T
{
  change() { ...};
  lookat() { ...} const;
}

      T f1(){ ...};
const T f2(){...};

f1().change(); // should be OK
f2().change(); // should be an error
f2().lookat(); // should be OK

Helmut Jarausch
Institute of Technology
RWTH-Aachen
Germany
---
[ 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 
]