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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,6cba88feacd3c2c5 X-Google-Attributes: gid103376,public From: "Kevin J. Weise" Subject: Re: Continue/next statement, static variables, and block comments Date: 1996/07/22 Message-ID: <4t05mo$f6d@michp1.redstone.army.mil> X-Deja-AN: 170048378 references: <4ssspn$501@umbc10.umbc.edu> content-type: text/plain; charset=us-ascii organization: Redstone Arsenal, Alabama mime-version: 1.0 newsgroups: comp.lang.ada x-mailer: Mozilla 1.22 (Windows; I; 16bit) Date: 1996-07-22T00:00:00+00:00 List-Id: mabzug1@umbc.edu (Mordechai T. Abzug) wrote: >Many languages provide a means to bypass the current iteration of a loop >without terminating the loops, ie. C's continue or Perl's next. Ada >doesn't seem to have one, despite having an exit statement, which is >extremely similar in nature to the continue. Is there something I'm >missing? I could, of course, model "continue" using if's, but a genuine >continue or next is more natural, reads better, and works better in case >statements. Anyone know of a suitable substitute? Without wishing to start a religious war (please!), I believe the language designers figured that the equivalent of the C "continue" was unnecessary. Indeed, one could argue that loop ... if condition then ... end if; end loop; is more readable than loop ... if condition then continue; ... end loop; since it is more apparent that there are statements affected by the "if". Of course, one could argue that badly indented source code could be just as easily misread, although semantically equivalent; or that exit when condition; is just as guilty. Mea culpa. This is probably just one of those "personal preferences". I like the "exit when ...", but don't care much for the C "continue". > >Another problem is static variables, ie. variables which are only visible >inside a function but retain their value across multiple invocations of >the funcyion. Again, I can model this (putting the function and the >variable in their own dummy package), but don't know a way to do it >naturally. One merely needs to follow scope. You want a variable to retain its value between invocations of a subprogram, make it non-local to that subprogram. If the subprogram is a library unit, you don't have much choice in Ada83 except to make your static variables visible in a package. The downside to this approach is that anything else that "withs" this package can change those variables without the subprogram knowing about it. In Ada95, you could potentially make the subprogram a child of the package so that the static variables don't need to be visible. There's also some aspect of Ada95 that I haven't yet investigated where packages can be made private. I assume this means one can control which library units can have access to another library unit's interface. >One last question (well, this one's more in the way of a gripe, since I'm >fairly certain I'm not missing anythhing here): no block commenting. >Line comments are a superior way of commenting when documentation is the >only thing you have in mind, but if you want to comment out a large >section of code, you want block comments. My makeshift here is an "if >false then. . . endif;" pair, but of course, it only works for executable >statements, not declarations. . Well, the latter portion of this gripe is true; and I have also wished for something along the lines of a compiler switch to accept or ignore code. But then again, I've seen C code where such practices were so abused that the product was grotesquely difficult to read & understand. In a similar vein, I've seen too much confusing code where the author(s) commented out blocks of code & it wasn't apparent to me if it was old code that needed to be deleted (but wasn't because the "programmer" wasn't sure if that was the needed correction) or anticipated upgrade code for future capabilities. In any case, block comments of this nature are difficult to detect the further apart the beginning and end of the block are from each other. Of course, I understand the intent is to clean it up when the software is "finished" or "ready"; quite often this is done. Quite often, it isn't done, too. Nested blocks in both situations are nightmares for someone unfamiliar with the code. This is not just a C-ism, either; I used to get dinged by this in other peoples' SIMULA code when I was in college. I believe that if one needs to retain segments of code for historical reasons, then a CM tool, such as DEC VAX/CMS or Unix CVS/RCS is a far better mechanism for doing so. (There are better CM tools, of course, but a simple checkout/checkin tool should suffice). I prefer to use tools & stand by the Ada solution. > >So, anyone have any constructive suggestions? Please don't tell me I >should just do this in C -- for various reasons, Ada makes sense for the >project as a whole. I just have a few problems with it. My best suggestion (and I hope this is taken in the good spirit in which it is intended) is to make an Ada solution, rather than a C solution in Ada syntax. The practices you mention are considered "poor form", even though they are widely used with other languages. > >-- > Mordechai T. Abzug >http://umbc.edu/~mabzug1 mabzug1@umbc.edu finger -l mabzug1@gl.umbc.edu >In God we trust. All others pay cash. --------------------------------------------------------------------- Kevin J. Weise email: kweise@sed.redstone.army.mil COLSA Corporation voice: (205) 842-9083 Huntsville, AL .. standard disclaimers apply