[OT-ish] goto and dijkstra
max101000010.01000101
quotes. since it applies also to a barely used c construct, i think it would
be informative to hear from some clc regulars, given their will to
comment... here:
2. "Restrict the use of the go to statement to alarm exits."
This is an oft quoted principle, that it is ok to use GOTO if you are
within a series of loops or subroutines, some sort of error is
detected, and the language allows you to terminate all of them in one
step.
I have never found this to be wise. The reason is, you should be
prepared to "clean up" each level above you, rather than aborting the
whole process. Even if you need to stop the whole process, loops or
subroutines above you may have files open, or need to send a message
to an operator that a particular step in the process has reached an
error, etc.
I generally pass back a value that tells each level above me if an
error occurs, so that they can each finish their business, then exit
up to the next level. Even if there is nothing to do at some
particular level, the logic/flow should be coded just in case (heaven
forbid) someone might want to change the code and add such a clean up
process before leaving the subroutine.
Agree or disagree?
Bjorn Reese
> Agree or disagree?
I agree and disagree. There are situations where goto is best suited,
and there are situations where it isn't -- just like any other part
of the language. I would advice that you avoid adopting a dogmatic
stance on goto.
Btw, Dijkstra did not advice against the use of goto, but rather
against the unbridled use of goto (although some people have
difficulty differentiating between the two.)
max101000010.01000101
"Bjorn Reese" <bre...@mail1.stofanet.dk> ha scritto nel messaggio
news:3DD78803...@mail1.stofanet.dk...
> "max101000010.01000101" wrote:
>
> > Agree or disagree?
>
> I agree and disagree. There are situations where goto is best suited,
> and there are situations where it isn't -- just like any other part
> of the language. I would advice that you avoid adopting a dogmatic
> stance on goto.
k&r did that too.
Sean Eby
news:kSLB9.19686$744.7...@news1.tin.it...
Agreed. Go to is essentially a branch (like any other branch or 'jump'
type of statement you would see in machine langauge). Hell, even the
do--while, while, and for loops in C (or any other language, for that
matter) will generate object code that is just has branch statements;
the computer has no idea what a 'for loop' or a 'while loop' is. It can
do some comparisons and branch on pre-defined conditions. So, with that,
even in a higher-level language (or is C medium-level language?) the go
to's are hidden behind those little curly braces that define your loops.
goto is part of the C language and therefore, it is a tool, just like
any other type of C construct. It should be used where it can be used
best, to keep code from getting way out of control. For instance, one
may not need to do a bunch of 'clean up' when you are eight or nine
levels deep in loops, but why stress your brain out to do 'clean up' by
checking some 'status condition' to see if it is time to stop the loop
that is running at that level? I say the use of goto might be wise in
this situation.
Consider this: Which loop is the best to use in C? It doesn't matter!
You can (with a little effort) make every type of loop accomplish
anything that you can accomplish with any other type of loop. You can
write a while loop to replace a for loop to replace a do--while loop to
replace a another while loop. It doesn't matter... as long as it
generates the correct object code. That is all that matters.
Sean
Thomas Stegen
> (or is C medium-level language?)
I think this is a defintion that depends on context.
If I say "A low-level language like C and a high-level
language like Common Lisp" you can not tell me I am wrong.
Same thing applies to the [partial] statement "high-level
language like C and Java". Depends on context and there is
no need to have a rigid definitions that spans all contexts.
That is the way it should be IMHO.
--
Thomas.
John L
"Sean Eby" <speb...@mindspring.com> wrote in message news:ar8np9$c8l$1...@husk.cso.niu.edu...
It may be "all that matters" to the machine, but a maintenance
programmer might beg to differ. You are right that we can program
in any language we like (Turing machines etc). The reason we don't
is that ease of expression and comprehension and syntactical sugar
really do matter. Honest.
Even to the compiler or interpreter which has to optimise and run
our programs.
John.
Alexander Terekhov
"max101000010.01000101" wrote:
>
> a guy in sci.math posted a personal comment about one of the famous dijkstra
> quotes.
Rather interesting reading:
http://www.cs.utexas.edu/users/EWD/ewd13xx/EWD1308.PDF
(What led to "Notes on Structured Programming", 2001)
regards,
alexander.
Dan Pop
>do some comparisons and branch on pre-defined conditions. So, with that,
>even in a higher-level language (or is C medium-level language?) the go
The traditional classification, that is still in current use, is:
o Machine code languages.
o Assembly languages.
o High level languages (HLL).
The assembly languages are still very tightly bound to the hardware,
they just hide the raw stream of ones and zeros from the programmer.
In their simplest form, each line of assembly generates one machine
code instruction. Macros (and other, more sophisticated, features)
allow the generation of many machine code instructions from one line
of assembly code, but the correspondence between the two is still
very well defined at the assembly language level.
High level languages have an abstraction layer from the hardware.
It is no longer possible (from the language definition) to tell what
kind of machine code will be generated by one line of high level language
code. Furthermore, at different optimisation levels, the same compiler
may generate different sequences.
However, the abstraction layer can be more or less transparent and
this is one of the criteria that decide which HLL is higher level than
the other. In C, many aspects of the hardware can be still peeped at
and the implementation of an algorithm is often closer to what the machine
can do in a few instructions than to the problem that has to be solved.
This is why C is a relatively low level HLL. However, there are still
lower level HLLs, like Forth.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan...@ifh.de