Deutsch   English   Français   Italiano  
<86pllhc8q0.fsf@linuxsc.com>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c
Subject: Re: goto considered helpful (Was: question about linker)
Date: Tue, 24 Dec 2024 09:05:27 -0800
Organization: A noiseless patient Spider
Lines: 86
Message-ID: <86pllhc8q0.fsf@linuxsc.com>
References: <vj1bss$325uo$1@dont-email.me> <vj1h4i$335q1$2@dont-email.me> <vj1mhi$34p7h$1@dont-email.me> <vj1prj$35je4$1@dont-email.me> <vj7dup$he7i$1@dont-email.me> <vjasuj$17uod$1@dont-email.me> <vjc87h$1apid$1@paganini.bofh.team> <vjcbe1$1jns0$1@dont-email.me> <87wmg5x4b1.fsf@nosuchdomain.example.com> <vjd96b$1pbed$1@dont-email.me> <87jzc5wx3s.fsf@nosuchdomain.example.com> <vjdde8$1q2to$2@dont-email.me> <87frmtwuzq.fsf@nosuchdomain.example.com> <20241212144454.00003b83@yahoo.com> <aqpamjh4h4kmu34ilbe5bnsiq4o7llso06@4ax.com> <20241220152722.00000327@yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Tue, 24 Dec 2024 18:05:30 +0100 (CET)
Injection-Info: dont-email.me; posting-host="0b35227985084685f7db26e049ff6a4a";
	logging-data="2062153"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/JqP9N5KdF7xKxJ/uV3c/8OPXbPbPWCgA="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:wjvwZ2maFL94b2RW8sy+kE/DN2g=
	sha1:RrIZvLEIKqwywz2hZfB+QjKCHFM=
Bytes: 5360

Michael S <already5chosen@yahoo.com> writes:

> On Fri, 20 Dec 2024 13:52:13 +0100
> Rosario19 <Ros@invalid.invalid> wrote:
>
>> On Thu, 12 Dec 2024 14:44:54 +0200, Michael S  wrote:
>>
>>> On Wed, 11 Dec 2024 17:27:53 -0800
>>> Keith Thompson > wrote:
>>>
>>>> bart > 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

I don't agree with this strategy.  More explanation below.

>> goto is not harmful in every case, if the people that write it,
>> indent that goto significally and have clear in mind and in the
>> text, what that goto has to do
>
> I don't agree.  Many sorts of goto are hard to understand for the
> reader even when they are crystal clear to the writer [at the
> moment of writing].
> That applies to nearly all forward gotos into block and to nearly
> all backward gotos.  That is, there exists one sort of backward
> goto that I find sufficiently understandable, but right now I am
> unable to formalize its exact properties.
>
> Of course, nothing of said above is relevant in context of gotos
> that exit inner loops.

In my view using goto should always be done on a case-by-case basis
and not under any general rule.  More specifically, when first
writing a function it should be written without using goto (which is
always possible).  If something about the code feels off, write it
another way, still without using goto.  Continue re-writing in this
way as long as the results are dissatisfying, up to perhaps four or
five versions (in some cases I have done a lot more than that).  In
many cases function bodies start off too large, and the code can be
simplified and clarified by breaking a function into several smaller
sub-functions;  doing that often removes any sense that goto is
needed.

After making multiple attempts, if none of the alternatives reaches
a suitable subjective quality assessment, then trying writing a
version with goto (or perhaps several versions, depending on other
factors).  If the best using-goto version is judged better than the
best non-goto version, then use it;  otherwise use the best non-goto
version.

I might add that I do end up using goto (rarely) in various unusual
circumstances, and some of those uses are truly horrific.  I am
content that they are appropriate because the non-goto versions
tried have all been worse along one or more axes.

> At large, Dijkstra is more right than wrong.

In my reading Dijkstra's point is not that goto should be avoided
but that teaching goto should be avoided:  student who learn to
write code using goto tend to produce tangled messes, at least more
than do those who are taught to use structured patterns of control
and not taught to use goto.  Reportedly Dijkstra has said that he is
not dogmatic about avoiding the use of goto, but it's important also
to understand the original point:  using goto should never be the
first line of defense, and education should reinforce that aphorism.