comp.lang.ada
 help / color / mirror / Atom feed
From: "Kevin J. Weise" <kweise@c3i-ccmail.sed.redstone.army.mil>
Subject: Re: Continue/next statement, static variables, and block comments
Date: 1996/07/22
Date: 1996-07-22T00:00:00+00:00	[thread overview]
Message-ID: <4t05mo$f6d@michp1.redstone.army.mil> (raw)
In-Reply-To: 4ssspn$501@umbc10.umbc.edu


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.   <sigh>.

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





  parent reply	other threads:[~1996-07-22  0:00 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1996-07-21  0:00 Continue/next statement, static variables, and block comments Mordechai T. Abzug
1996-07-21  0:00 ` Michael Feldman
1996-07-22  0:00 ` Kevin J. Weise [this message]
1996-07-23  0:00   ` Kevin J. Weise
1996-07-23  0:00     ` Robert A Duff
1996-07-24  0:00       ` Dale Stanbrough
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox