From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32124 invoked by alias); 4 Jan 2003 18:47:34 -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 32117 invoked from network); 4 Jan 2003 18:47:33 -0000 Received: from unknown (HELO fencepost.gnu.org) (199.232.76.164) by 209.249.29.67 with SMTP; 4 Jan 2003 18:47:33 -0000 Received: from monty-python.gnu.org ([199.232.76.173]) by fencepost.gnu.org with esmtp (Exim 4.10) id 18UtKL-0007m5-00 for gcc@gnu.org; Sat, 04 Jan 2003 13:47:21 -0500 Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10.13) id 18UtJE-00074B-00 for gcc@gnu.org; Sat, 04 Jan 2003 13:46:14 -0500 Received: from smtp02.web.de ([217.72.192.151] helo=smtp.web.de) by monty-python.gnu.org with esmtp (Exim 4.10.13) id 18UtIS-0006Uq-00 for gcc@gnu.org; Sat, 04 Jan 2003 13:45:24 -0500 Received: from [80.130.179.120] (helo=ws1.tarantula.dnsalias.org) by smtp.web.de with asmtp (WEB.DE(Exim) 4.93 #1) id 18UtIQ-0002PH-00 for gcc@gnu.org; Sat, 04 Jan 2003 19:45:22 +0100 Date: Sat, 04 Jan 2003 18:54:00 -0000 From: Tolga Dalman To: gcc@gnu.org Subject: Re: c++ "with" keyword Message-Id: <20030104191550.74bb84e2.ates100@web.de> In-Reply-To: <3E1723FB.5020604@chaincast.com> References: <20030104142915.3BD6EF2DF9@nile.gnat.com> <87el7tneoh.fsf@merlin.maxx.bg> <15894.64524.464371.216489@cuddles.cambridge.redhat.com> <3E171A85.8030008@chaincast.com> <20030104182546.50c4d558.ates100@web.de> <3E1723FB.5020604@chaincast.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=-7.4 required=5.0 tests=EMAIL_ATTRIBUTION,FROM_ENDS_IN_NUMS,IN_REP_TO, QUOTED_EMAIL_TEXT,REFERENCES,SPAM_PHRASE_00_01 version=2.41 X-Spam-Level: X-SW-Source: 2003-01/txt/msg00155.txt.bz2 On Sat, 04 Jan 2003 10:12:11 -0800 Gianni Mariani wrote: > Tolga Dalman wrote: > > >On Sat, 04 Jan 2003 09:31:50 -0800 Gianni Mariani wrote > > > > > >> > >>So, I'd like to steer the discussion back to the merits of "with". > >> > >>The "with" syntax was a pain in the rear in Pascal and I never want to > >>see it again - this is why: > >> > >>Take 2 structures, A and B which are both used in a "with" statement. > >> > >>e.g. (I'll use the proposed new "with" syntax in c++ below) > >> > >>Let's start with some valid working code ... > >> > >>struct A { > >> int X; > >> int Y; > >> int hUgH; > >>}; > >> > >>struct B { > >> int Z; > >>}; > >> > >>int func() > >>{ > >> .... > >> A & a; > >> B & b; > >> .... > >> > >> with ( a ) > >> witb ( b ) > >> { > >> > >> Y = Z; > >> hUgH = X; // woz this then eh ? <-- point of confusion > >> } > >> ... > >>} > >> > >>And a little later someone comes and fixes a bug and adds > >> > >>struct B { > >> int Z; > >> int X; // need an X to fix The Bug (tm) > >>}; > >> > >>Oops - which X is now instantiated at "point of confusion" ? > >> > >>Someone innocently added a new member and completly changed the > >>behaviour of the code. For code maintainability, I'd suggest that this > >>would cause more difficult to discover problems than would be merited. > >> > >> > >> > > > >it should be possible to disallow a "with" keyword within another "with" block. > > > > > It becomes MUCH less useful if you do this and hence I'll argue that it > makes little sense to have a "with" at all. > In almost every case where I used the "with" keyword in my distant past, > I remember that I was dealing with at least 2 structures and messing > with them together. i understand. "with" is comparable to the switch-case construct. there, you aren't allowed to uses cascaded switch'es. i'm happy to have it anyways, and i believe a with would be aswell useful. additionally, i don't think there's a (efficient, at least) way to solve the ambiguity problem for multiple withs. > > >>This is also one of the reasons I don't like namespaces much either - > >>hence I allways prefix identifiers that are not within a class's scope. > >> > >> > >> > > > >hm, i know a lot of people who don't like namespaces aswell, but the point is: > >it'd be great to have a compiler-feature to make code more readable. > >i think, long struct-names are very annoying and a common solution > >(either standard or compiler-addon) for this problem would be very good. > >just my opinion. > > > > > > But there is, as has been explained :) > > { > A & y = long_descriptive_expression_I_dont_like_repeating; > B & z = long_descriptive_expression_I_dont_like_repeating; > > z.memberA = z.memberB; > z.memberB = y.memberA; > } > > ... Totally unambiguous, very readable, no new syntax - QED. > ... and potentially two new variables in your code and binary. what i wanted to have: { #define y long_descriptive_expression_I_dont_like_repeating; #define z long_descriptive_expression_I_dont_like_repeating; z.memberA = z.memberB; z.memberB = y.memberA; #undef z #undef y } but this is just ugly. no offense, but you state you wouldn't like namespaces, on the other hand you propagate using new variables within a new block to be less confusing? > > > > > >>If you were to implement (heaven forbid) the "with" mechanism, I'd > >>suggest you use the "using" keyword instead. > >> > >> > >> > > > >the actual name doesn't matter i think, but "with" is already used in other programming languages. so, why to use "using"? > > > sematically similar meaning of the keyword - it's just a suggestion. > one reason against the with keyword would be that there's one more word in our C vocabulary. a (programming-)language with too many words is rather unattractive, i'd say. Tolga Dalman.