From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22292 invoked by alias); 22 Nov 2004 23:57:38 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 22254 invoked from network); 22 Nov 2004 23:57:33 -0000 Received: from unknown (HELO uniton.integrable-solutions.net) (62.212.99.186) by sourceware.org with SMTP; 22 Nov 2004 23:57:33 -0000 Received: from uniton.integrable-solutions.net (localhost [127.0.0.1]) by uniton.integrable-solutions.net (8.12.10/8.12.10/SuSE Linux 0.7) with ESMTP id iAMNv0Q0014104; Tue, 23 Nov 2004 00:57:01 +0100 Received: (from gdr@localhost) by uniton.integrable-solutions.net (8.12.10/8.12.10/Submit) id iAMNv0KY014103; Tue, 23 Nov 2004 00:57:00 +0100 X-Authentication-Warning: uniton.integrable-solutions.net: gdr set sender to gdr@integrable-solutions.net using -f To: Matt Austern Cc: Andrew Pinski , Steve Naroff , gcc mailing list , Michael Matz , Ziemowit Laski , Joe Buck , Mike Stump Subject: Re: generalized lvalues -- patch outline References: <4D2CF60C-3919-11D9-8BD2-000A95BCF344@apple.com> <20041117212847.A26376@synopsys.com> <6F5FC748-7BBD-44B9-8DDC-246949F16102@apple.com> <20041118102741.A8347@synopsys.com> <77E8D36A-C0C2-4B03-964C-BEE0FE7BBBC3@apple.com> <98C86CD4-39E2-11D9-B2D5-000A95BCF344@apple.com> <20041119170011.A30410@synopsys.com> <9E6AD708-3A93-11D9-9070-000D9330C50E@apple.com> <20041119174042.A1311@synopsys.com> <90DC5074-3A96-11D9-9070-000D9330C50E@apple.com> <9CD04F70-3CC6-11D9-B847-000D9330C50E@apple.com> <7688EB08-3CC7-11D9-AEB4-000A95D692F4@physics.uc.edu> From: Gabriel Dos Reis In-Reply-To: Organization: Integrable Solutions Date: Tue, 23 Nov 2004 00:04:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-11/txt/msg00768.txt.bz2 Matt Austern writes: | On Nov 22, 2004, at 12:45 PM, Andrew Pinski wrote: | | > | > On Nov 22, 2004, at 3:39 PM, Ziemowit Laski wrote: | > | >> On 19 Nov 2004, at 17.50, Ziemowit Laski wrote: | >> | >>> To put it another way, I'm only concerned with cases where the | >>> compiler currently complains | >>> about assigning to a non-lvalue, and the non-lvalue in question is | >>> a cast of an lvalue. | >> | >> Indeed, I now appear to have a mainline mod for C and C++ which | >> allows assignment to lvalue casts for pointer types. What follows | >> is a high-level synopsis of what I did; if there is interest, I can | >> whip up a full-fledged patch, complete with docs. Please let me | >> know. | > | > | > Just use a builtin as proposed by Nathan and others for the problem you | > are trying to solve. The syntax for casts as lvalue just looks bad. | > The builtin can return a reference (yes even in the C front-end you | > can have references [varargs is an example of which is used as | > references in the front-end]). | | Unfortunately, there is another reason for allowing some tamed version | of assignment to casts: compatibility with other compilers. Microsoft | and CodeWarrior both allow this in one form or another. (Microsoft | for C only, CodeWarrior for C++ as well. CodeWarrior only allows some | limited forms of assignments to casts, and doesn't treat a cast as a | true lvalue, so they still get overload resolution right.) I fear there is a circular reasoning here: compilers tend to be bug+feature compatible; there are high chances that those mentioned compiler implement that dubious construct because gcc invented them in the first place. Now, saying those compilers implement that questionable construct as a reason to resurect that abomination does not sound right to me. -- Gaby