From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11214 invoked by alias); 24 Nov 2004 20:03:27 -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 10811 invoked from network); 24 Nov 2004 20:02:57 -0000 Received: from unknown (HELO colo.khms.westfalen.de) (213.239.196.208) by sourceware.org with SMTP; 24 Nov 2004 20:02:57 -0000 Received: from khms.vpn ([10.172.192.2]:46731 helo=khms.westfalen.de) by colo.khms.westfalen.de with asmtp (TLS-1.0:RSA_ARCFOUR_SHA:16) (Exim 4.34) id 1CX3Jq-00017E-3C for gcc@gcc.gnu.org; Wed, 24 Nov 2004 21:00:50 +0100 Received: from root (helo=khms.westfalen.de) by khms.westfalen.de with local-bsmtp (Exim 4.34) id 1CX3Je-0002qm-SE for gcc@gcc.gnu.org; Wed, 24 Nov 2004 21:00:38 +0100 Received: by khms.westfalen.de (CrossPoint v3.12d.kh14 R/C435); 24 Nov 2004 20:49:44 +0200 Date: Wed, 24 Nov 2004 20:40:00 -0000 From: kaih@khms.westfalen.de (Kai Henningsen) To: gcc@gcc.gnu.org Message-ID: <9LVefXpXw-B@khms.westfalen.de> In-Reply-To: Subject: Re: generalized lvalues -- patch outline MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Organization: Organisation? Me?! Are you kidding? References: <4D2CF60C-3919-11D9-8BD2-000A95BCF344@apple.com> <7688EB08-3CC7-11D9-AEB4-000A95D692F4@physics.uc.edu> : > 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. That's a somewhat circular history, but I can't see any circular reasoning. If the goal is (say) MS compatibility, it doesn't matter if MS is the way it is because it wanted to be somewhat gcc compatible, or because they independently had the same idea, or whatever. It just matters that they are the way they are. In any case, *if* something like that comes back, I think it should be done this way: 1. To get it, you need an explicit flag of some kind - it's not there by default, so we have a guarantee that it doesn't hurt programs which don't use it. (I have no preferences as to what flag would be appropriate, just that it be off by default.) 2. It is defined exactly what it does, preferrably as a syntactic transform to a standard (or at least different) language construct (this also helps people who want to get rid of it). For example (and I don't claim this is the semantic it ought to have), modification((type)lvalue) -> ({ type __tmp = (type)lvalue; modification(__tmp); lvalue = (typeof(lvalue))__tmp; lvalue; }) (and similarly for any other allowed general lvalue constructs). MfG Kai