🚀 go-pugleaf

In article <DAVEW.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.  I assume this has been discussed to death
|> here before, but I haven't been able to find it in a FAQ; I'd be happy
|> with a reference to another document rather than a full reply here.

First: it wasn't the committee's decision (except in so far as they
didn't change the base document).  This was illegal in the ARM.

Consider the following:

    void
    incr( int& i )
    {
        i ++ ;
    }

    unsigned        j = 1 ;
    incr( j ) ;

Without the rule, the above is perfectly legal code.  However, the call
to `incr' does *NOT* modify `j', as the programmer probably expected it
would.  The reason is that incr takes an int, not an unsigned.  The
compiler implicitly converts, but the result of this conversion is not
an lvalue, but a temporary, and it is the temporary that gets bound to
the reference parameter.

I don't know when this rule was introduced, but it has been present in
all C++ texts I've seen except the first edition of Stroustrup (1986).
(Note that the exact example above appears on page 86 of _The Design_
_and_Evolution_of_C++.  Given that this was originally allowed, and that
actual practical experience found it to be a mistake, it was hardly
likely that the committee would undo it.)

There have been suggestions that only implicit conversions should be
banned, and not all rvalues.  However, as far as I know, no one ever
came up with a concrete proposal along these lines, and I believe that
the standard is too far advanced now to make the change (although it
sure would simplify the problems with auto_ptr:-).

|> The only answer I've seen for this question before is that it is
|> disallowed because the reference may outlive the rvalue it refers to.

If you want to know why certain features are (or are not) in C++, you
should definitly read the above mentioned book.
-- 
James Kanze           (+33) 88 14 49 00          email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle --
                            -- Beratung in industrieller Datenverarbeitung


[ 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                             ]