From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,4b06f8f15f01a568 X-Google-Attributes: gid103376,public From: adam@irvine.com Subject: Re: Software landmines (was: Why C++ is successful) Date: 1998/08/18 Message-ID: <6rd27s$ffi$1@nnrp1.dejanews.com>#1/1 X-Deja-AN: 382435032 References: <6qfhri$gs7$1@nnrp1.dejanews.com> <35cb8058.645630787@news.ne.mediaone.net> <902934874.2099.0.nnrp-10.c246a717@news.demon.co.uk> <6r1glm$bvh$1@nnrp1.dejanews.com> <6r9f8h$jtm$1@nnrp1.dejanews.com> Organization: Deja News - The Leader in Internet Discussion X-Article-Creation-Date: Tue Aug 18 23:20:27 1998 GMT Newsgroups: comp.lang.ada X-Http-User-Agent: Mozilla/3.0 (X11; I; Linux 2.0.18 i586) Date: 1998-08-18T00:00:00+00:00 List-Id: In article <6r9f8h$jtm$1@nnrp1.dejanews.com>, dennison@telepath.com wrote: > In article , > dewar@merv.cs.nyu.edu (Robert Dewar) wrote: > > T.E.D says > > > > But it's a toss up in this case, and for most purposes we would prefer > > the second case. Where it gets tricky is > > > > for J in 1 .. N loop > > if condition 1 then > > ... > > if condition 2 then > > ... > > if conditoin 3 then > > goto Continue; > > > > Now T.E.D's prescription is not so clear, and we end up having to > > severely contort things, or introduce a boolean flag which we keep > > testing as we unwind to the end. > > > > Remember that the continue here is just like a return. If you are allergic > > to using a loop continue or exit, you should be allergic to using a return > > (other than at the end of a function). Some people are, and that is at > > least consistent. But I see a lot of Ada programmers who will use a return > > without hesitation from a nested loop, but still turn green at the sight > > of a goto. That makes no sense to me. > > > > Good point. Typically in this case I would "cheat" it and embed the inside of > the loop in a subprogram, with a return statement. . . . I've been thinking about a similar problem that I keep running into, where you execute a sequence of statements, and after many of the statements, you have to make some test to ensure that the statement was successful or that your pointers aren't null or that you don't have garbage data or something like that. I don't like code like blah-blah-blah; if not error-condition-1 then keep-going; if not error-condition-2 then still-keep-going; if not error-condition-3 then everythings-still-fine-keep-going; etc. because it's hard to read unless you have a terminal that's shaped like a parallelogram. Also, if you keep this up, you end up being able to put only 30 characters on a line, and it takes 3 lines to code one Ada statement. Having a flag that you keep testing is one alternative. So is "goto". So is T.E.D's workaround of putting the code in a subprogram and using "return". So is defining a local exception: declare error : exception; begin blah-blah-blah; if error-condition-1 then raise error; end if; keep-going; if error-condition-2 then raise error; end if; still-keep-going; if error-condition-3 then raise error; end if; everythings-still-fine-keep-going; etc. exception when error => ... end; Question: Would you expect the compiler to optimize the "raise error" to a simple branch to the exception handler in this case, assuming the exception handler didn't contain any statements that depended on Ada's exception features? Note that I think using a local exception is an option *only* because the thing I'm testing for is an error condition; it wouldn't be appropriate for most other types of conditions. Anyway, here's my main question: Is it desirable to expand the syntax of "exit" to cover cases like this? I think it might be nice. I'm thinking that code like this could look something like: block_to_do_stuff: begin blah-blah-blah; exit block_to_do_stuff when error-condition-1; keep-going; exit block_to_do_stuff when error-condition-2; still-keep-going; exit block_to_do_stuff when error-condition-3; everythings-still-fine-keep-going; etc. end block_to_do_stuff; I think one of the Ada 9X proposals actually had a feature like this, but unfortunately it also changed the semantics of "exit" in a way that would change the meanings of a lot of Ada 83 code. Probably, that's why it was dropped from the final Ada 95 definition. But I think that the exit-block feature in my example would be a very useful addition to the next version of Ada. (I'd define it so that this use of "exit" requires a block name, so that the semantics of "unnamed" exit statements are unchanged; that way, there wouldn't be any upward compatibility problems.) So do the rest of you think it's a useful enough feature to consider adding to Ada? -- Adam -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum