* Re: Continue/next statement, static variables, and block comments
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
1 sibling, 0 replies; 6+ messages in thread
From: Michael Feldman @ 1996-07-21 0:00 UTC (permalink / raw)
In article <4ssspn$501@umbc10.umbc.edu>,
Mordechai T. Abzug <mabzug1@umbc.edu> wrote:
>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.
It's perfectly natural to encapsulate state information in an enclosing
unit of some kind. Indeed, it's how OO languages do it. You have a problem
only because you're thinking in terms of isolated functions instead of
encapsulsated sets of functions operating on variables (objects, whatever).
>
>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>.
How about something revolutionary: an editor that lets you insert
-- at the begining of a range of lines. :-)
BTW - suppose you have a 24-line editor window and then use C-or Pascal-
style commenting to "comment out" a 50-line block of code? Then you
scroll the middle 24 lines into your window. How do you know whether
it's active code, or commented out? _That's_ the real virtue of line
commenting!
Mike Feldman
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Continue/next statement, static variables, and block comments
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
1996-07-23 0:00 ` Kevin J. Weise
1 sibling, 1 reply; 6+ messages in thread
From: Kevin J. Weise @ 1996-07-22 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 6+ messages in thread