🚀 go-pugleaf

In article <DAVEW.96Apr3110726@trigati.cs.haverford.edu>
davew@trigati.cs.haverford.edu (David G. Wonnacott) writes:

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

My understanding is that what happens in the case of "illegal" programs
is not defined by the standard.  For a certain category of errors, the
standard states that the compiler must issue a diagnostic; once that
occurs, you have undefined behavior.  (I think that we all would agree,
however, that it would be a pretty poor implementation that would go on
and do something bad having recognized an error.  But as some one once
pointed out to me in email: the `diagnostic' doesn't have to be on the
screen.  The implementor is free to document something to the effect
that `the diagnositic for errors requiring such in the standard is to
cause the light on the front of the hard disk to light up for 45
sec./Megabyte storage capacity.)

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

In the case of `int', I don't think there are any good choices.  But in
the case of `int', I don't think you need them.  For a user defined
class, I would certainly look into what could be done with mutable, and
declaring the parameters constant.
-- 
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils, études et réalisations en logiciel orienté objet --
                -- A la recherche d'une activité dans une region francophone
---
[ 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 
]