Sujet : Re: goto considered helpful
De : 643-408-1753 (at) *nospam* kylheku.com (Kaz Kylheku)
Groupes : comp.lang.cDate : 12. Dec 2024, 23:33:46
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <20241212141108.871@kylheku.com>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
User-Agent : slrn/pre1.0.4-9 (Linux)
On 2024-12-12, Keith Thompson <Keith.S.Thompson+
u@gmail.com> wrote:
Michael S <already5chosen@yahoo.com> writes:
On Wed, 11 Dec 2024 17:27:53 -0800
Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
bart <bc@freeuk.com> writes:
[...]
My experience of multi-level break is that there are two main
use-cases:
>
* Used in the current loop only (not necessarily the innermost to
an observer). This is the most common
>
* Used to exit the outermost loop
>
So to support these, named or even numbered loops are not
necessary. (Eg. I use 'exit' or 'exit all'.)
I would oppose a change to C that only applied to innermost and
outermost loops. For one thing, I'm not aware of any other language
that does this (except perhaps your unnamed one). For another,
it's easy enough to define a feature that handles any arbitrary
nesting levels, by applying names (labels) to loops.
>
The better solution is education.
Convince teachers in unis and colleges that goto is *not* considered
harmful for this particular use case. Convince them to teach that
attempts to avoid goto [for this particular use case] are really
considered harmful. If you don't believe in authority of yourself then
ask for help from somebody famous that share this view. I would guess
that nearly all famous C programmers share it.
>
Backward gotos tend to be dangerous. Forward gotos are less so.
Backwards gotos are still fine if they are used to create a program
graph that is also possible with structured control constructs.
Compilers can still do loop analysis on the intermediate code and such.
Backwards gotos can make control flow graphs that are in a different class,
not expressible with conventional control constructs, like:
if (condition1) {
// ...
label1:
statement1;
}
if (condition2) {
goto label1;
}
There are reasons for a coding convention around goto to disallow
this, even if it allows backwards goto.
Note how it is possible to execute "goto label1" without having ever
executed the destination statement "statement1" before.
In other words, the label1 node does not /dominate/ the goto.
A coding rule against this might therefore be worded something like:
"only true backwards gotos are allowed: every backwards goto must go to a node
in the program which dominates the goto statement".
-- TXR Programming Language: http://nongnu.org/txrCygnal: Cygwin Native Application Library: http://kylheku.com/cygnalMastodon: @Kazinator@mstdn.ca