johnchx posted:

> jpotter@lhup.edu (John Potter) wrote
>> johnchx2@yahoo.com (johnchx) wrote:
>>
>> > Perfectly legal.  Your reasoning -- that the fact that an expression
>> > is an rvalue does not mean that the object it denotes is const -- is
>> > correct.
>>
>> However, you missed the subtleties of 8.5.3/5.  We reach the final
>> otherwise which requires construction of a temporary CONST int for
>> binding with the reference.  Modifying this constant is undefined
>> behavior.
>
> Egad.  So it would seem.  The rvalue isn't const, but the copy is.
>
> Even more interesting is the case of an rvalue of class type, in which
> the object bound to the reference may or may not be const, depending
> on whether the implementation performs a copy.
>
> Subtle indeed.


Well if the temporary is copied, then is there any advantage at all in
using:


AnyClass const &blah = FunctionThatReturnsAnyClass();

over:

AnyClass blah = FunctionThatReturnsAnyClass();


I was under the impression that the former was preferable as it avoids a
posssible copy... ?


-JKop

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

NULL@NULL.NULL (JKop) wrote
> Well if the temporary is copied, then is there any advantage at all in
> using:
>
>
> AnyClass const &blah = FunctionThatReturnsAnyClass();
>
> over:
>
> AnyClass blah = FunctionThatReturnsAnyClass();
>
>
> I was under the impression that the former was preferable as it avoids a
> posssible copy... ?
>

The compiler is free to make (or not make) a copy in either case.

There is an advantage to the reference form under certain special
circumstances: if the function returns (by value) an object of a class
derived from AnyClass, you can bind a reference-to-base to it without
slicing.

For an example of where this might come in handy, see:

  http://www.cuj.com/documents/s=8000/cujcexp1812alexandr/alexandr.htm

The key condition is that the function you're calling is an implicit
instantiation of a function template whose actual return type depends
upon the types of its parameters.

The advantage of the non-reference form is that the resulting object
is guaranteed non-const, and since the name is also declared
non-const, you don't even need the highly suspicious cast.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Given that the following is perfectly legal:


void Blah( int const& k )
{
    const_cast< int& > ( k ) = 2;
}

int main()
{
    int r;

    Blah( r );
}


because the original object was non-const; would it not be fair to say that
the following is also legal:


void Blah( int const& k )
{
    const_cast< int& > (k) = 2;
}

int main()
{
    Blah( int() );
}


My reasoning behind this is that the temporary object passed by reference to
"Blah" is in fact non-const (even though it is an r-value).


Is there any official stance on this?

While I'm at it, the only argument I've ever heard in favour of references
being r-value's is the following code:


void Blah(int &r)
{
     r += 5;
}

int main()
{
    float k = 78.2;

    Blah( k );
}


Obviously, one wants the actual "k" object to be altered, but what's
happening is that a temporary of type "int" must be created. Although this
temporary object is not const, it is still and r-value and so it cannot be
bound to a non-const reference.


-JKop

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Tue, 26 Oct 2004 21:22:30 GMT, NULL@NULL.NULL (JKop) wrote:

>
>Given that the following is perfectly legal:
>
>
>void Blah( int const& k )
>{
>    const_cast< int& > ( k ) = 2;
>}
>
>int main()
>{
>    int r;
>
>    Blah( r );
>}
[snip]

Yes, but read 5.2.11.7.

In general, we don't outlaw knives just because there is the danger
that you might cut yourself with one.

--
Bob Hairgrove
NoSpamPlease@Home.com

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

NULL@NULL.NULL (JKop) wrote

> because the original object was non-const; would it not be fair to say that
> the following is also legal:
>
>
> void Blah( int const& k )
> {
>     const_cast< int& > (k) = 2;
> }
>
> int main()
> {
>     Blah( int() );
> }

Perfectly legal.  Your reasoning -- that the fact that an expression
is an rvalue does not mean that the object it denotes is const -- is
correct.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

On Wed, 27 Oct 2004 16:34:47 GMT, johnchx2@yahoo.com (johnchx) wrote:

> NULL@NULL.NULL (JKop) wrote

> > because the original object was non-const; would it not be fair to say that
> > the following is also legal:

> > void Blah( int const& k )
> > {
> >     const_cast< int& > (k) = 2;
> > }

> > int main()
> > {
> >     Blah( int() );
> > }

> Perfectly legal.  Your reasoning -- that the fact that an expression
> is an rvalue does not mean that the object it denotes is const -- is
> correct.

However, you missed the subtleties of 8.5.3/5.  We reach the final
otherwise which requires construction of a temporary CONST int for
binding with the reference.  Modifying this constant is undefined
behavior.

John

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

jpotter@lhup.edu (John Potter) wrote
> johnchx2@yahoo.com (johnchx) wrote:
>
> > Perfectly legal.  Your reasoning -- that the fact that an expression
> > is an rvalue does not mean that the object it denotes is const -- is
> > correct.
>
> However, you missed the subtleties of 8.5.3/5.  We reach the final
> otherwise which requires construction of a temporary CONST int for
> binding with the reference.  Modifying this constant is undefined
> behavior.

Egad.  So it would seem.  The rvalue isn't const, but the copy is.

Even more interesting is the case of an rvalue of class type, in which
the object bound to the reference may or may not be const, depending
on whether the implementation performs a copy.

Subtle indeed.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]