Re: c++/7828: g++ 3.3: bad non-lvalue error (non_cast_lvalue_or_else)

[Scott Snyder <snyder@fnal.gov>]

The following reply was made to PR c++/7828; it has been noted by GNATS.

From: Scott Snyder <snyder@fnal.gov>
To: Andrew Pinski <pinskia@physics.uc.edu>
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: c++/7828: g++ 3.3: bad non-lvalue error (non_cast_lvalue_or_else)
Date: 05 Sep 2002 11:18:19 -0500

 >>>>> "Andrew" == Andrew Pinski <pinskia@physics.uc.edu> writes:
     Andrew> One question which libstdc++, because the version 3 is
     Andrew> fine and it compiles just fine with this patch?
 
 It was the head cvs version of libstdc++.
 The original call i had that was giving problems was like this:
 
       std::bind2nd (std::plus<unsigned long>(), 1)
 
 The implementation of bind2nd had the cast inside it.
 Hmm.. maybe it would work if the constant above is explicitly cast to an
 unsigned long --- unfortunately, the disk died yesterday on the machine
 i was testing this on, so i can't test it immediately.
 
     Andrew> Another point, it is invalid code, the problem is that the
     Andrew> casting does makes a variable not a lvalue.
 
 Yeah, but you shouldn't need an lvalue to pass through a const reference,
 right?  I thought that only a non-const ref needed an lvalue; a call
 through a const ref can use a temporary.
 [I can call `void foo(const int&)' with `foo(1)' --- `1' is certainly
 not an lvalue.]  My copy of the standard is in another office,
 so i can't verify what it says right now.
 
     Andrew> The error message is because when you pass an argument
     Andrew> into a function and that argument is a reference,
     Andrew> 	gcc tries to use the unary `&', which means take the
     Andrew> memory location that points to that lvalue.
 
 Yeah, i understand that --- but ideally, an error message should
 refer to the what's in the code the user wrote, not to the result
 of some internal transformation the compiler does.  Thus my
 comment about the message being confusing.
 
 thanks,
 sss