From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9612 invoked by alias); 5 Sep 2002 16:26:02 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 9598 invoked by uid 71); 5 Sep 2002 16:26:01 -0000 Date: Thu, 05 Sep 2002 09:26:00 -0000 Message-ID: <20020905162601.9597.qmail@sources.redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Scott Snyder Subject: Re: c++/7828: g++ 3.3: bad non-lvalue error (non_cast_lvalue_or_else) Reply-To: Scott Snyder X-SW-Source: 2002-09/txt/msg00081.txt.bz2 List-Id: The following reply was made to PR c++/7828; it has been noted by GNATS. From: Scott Snyder To: Andrew Pinski 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 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(), 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