Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #70089 > unrolled thread
| Started by | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| First post | 2019-11-28 12:19 -0800 |
| Last post | 2020-02-18 18:46 +0100 |
| Articles | 20 on this page of 113 — 20 participants |
Back to article view | Back to comp.lang.c++
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-28 12:19 -0800
Re: two's complement idea "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-11-29 00:14 +0100
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2019-11-29 09:15 +0100
Re: two's complement idea Bo Persson <bo@bo-persson.se> - 2019-11-29 10:58 +0100
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2019-11-29 12:49 +0100
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-12-07 07:53 -0800
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2019-12-07 08:22 -0800
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-10 20:44 -0800
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2020-01-10 23:44 -0800
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-14 07:08 -0800
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2020-01-14 08:42 -0800
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-21 02:09 -0800
Re: two's complement idea James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-21 05:14 -0800
Re: two's complement idea Daniel <danielaparker@gmail.com> - 2020-01-21 13:08 -0800
Re: two's complement idea James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-22 00:07 -0500
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2020-01-21 23:21 -0800
Re: two's complement idea Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-22 01:51 -0800
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-22 11:28 +0100
Re: two's complement idea Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-22 11:52 +0100
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2020-01-22 04:47 -0800
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-04-02 07:19 -0700
Re: two's complement idea James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-02 08:07 -0700
Re: two's complement idea boltar@nowhere.org - 2020-01-21 16:44 +0000
Re: two's complement idea Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-21 20:01 +0000
Re: two's complement idea boltar@nowhere.org - 2020-01-22 11:26 +0000
Re: two's complement idea Christian Gollwitzer <auriocus@gmx.de> - 2020-01-22 20:04 +0100
Re: two's complement idea Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-22 11:30 -0800
Re: two's complement idea Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2020-01-22 19:57 +0000
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-23 10:03 +1300
Re: two's complement idea boltar@nowhere.org - 2020-01-23 09:24 +0000
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-24 07:29 +1300
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-23 10:03 +1300
Re: two's complement idea "Fred. Zwarts" <F.Zwarts@KVI.nl> - 2020-01-23 10:09 +0100
Re: two's complement idea boltar@nowhere.org - 2020-01-23 09:29 +0000
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-24 01:08 +0000
Re: two's complement idea boltar@nowhere.org - 2020-01-24 12:27 +0000
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-24 01:06 +0000
Re: two's complement idea Bo Persson <bo@bo-persson.se> - 2020-01-24 10:07 +0100
Re: two's complement idea Paavo Helde <myfirstname@osa.pri.ee> - 2020-01-24 11:36 +0200
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2020-01-24 17:34 -0800
Re: two's complement idea Siri Cruise <chine.bleu@yahoo.com> - 2020-01-24 17:57 -0800
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-24 12:19 +0000
Re: two's complement idea Bo Persson <bo@bo-persson.se> - 2020-01-24 14:19 +0100
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-24 14:11 +0000
Re: two's complement idea Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-24 17:26 +0000
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-24 17:35 +0000
Re: two's complement idea Paavo Helde <myfirstname@osa.pri.ee> - 2020-01-24 22:27 +0200
Re: two's complement idea James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-24 23:21 -0500
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-25 11:06 +1300
Re: two's complement idea Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-24 22:12 +0000
Re: two's complement idea James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-24 23:24 -0500
Re: two's complement idea Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-25 09:04 +0000
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2020-01-25 04:15 -0800
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-25 19:55 +0100
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-25 00:05 +0100
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-25 01:19 +0000
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-25 19:50 +1300
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-25 11:57 +0000
Re: two's complement idea Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2020-01-25 13:42 +0000
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-25 14:58 +0000
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-26 07:58 +1300
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-25 20:34 +0100
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2020-01-25 12:41 -0800
Re: two's complement idea Paavo Helde <myfirstname@osa.pri.ee> - 2020-01-26 16:08 +0200
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-27 02:20 -0800
Re: two's complement idea Paavo Helde <myfirstname@osa.pri.ee> - 2020-01-27 15:03 +0200
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-15 06:44 -0800
Re: two's complement idea Paavo Helde <myfirstname@osa.pri.ee> - 2020-03-06 10:18 +0200
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-04-02 07:05 -0700
Re: two's complement idea Paavo Helde <myfirstname@osa.pri.ee> - 2020-04-02 20:03 +0300
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-04-04 12:37 -0700
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-26 07:45 +1300
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-25 19:56 +0000
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-26 09:49 +1300
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-25 21:33 +0000
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-26 11:00 +1300
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-25 22:23 +0000
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-26 11:46 +1300
Re: two's complement idea Paavo Helde <myfirstname@osa.pri.ee> - 2020-01-26 10:55 +0200
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2020-01-26 03:47 -0800
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-27 01:28 -0800
Re: two's complement idea Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-25 22:22 +0000
Re: two's complement idea James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-25 18:24 -0500
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-26 12:54 +0100
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-26 12:44 +0000
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-26 14:58 +0100
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-26 14:53 +0000
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-26 19:10 +0100
Re: two's complement idea Robert Wessel <robertwessel2@yahoo.com> - 2020-01-26 13:20 -0600
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-26 20:51 +0000
Re: two's complement idea Robert Wessel <robertwessel2@yahoo.com> - 2020-01-26 21:02 -0600
Re: two's complement idea Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-26 19:06 -0800
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-27 18:50 +0000
Re: two's complement idea Robert Wessel <robertwessel2@yahoo.com> - 2020-01-27 14:18 -0600
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-27 22:13 +0100
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-27 21:38 +0000
Re: two's complement idea Robert Wessel <robertwessel2@yahoo.com> - 2020-01-27 19:37 -0600
Re: two's complement idea Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-27 19:15 -0800
Re: two's complement idea "Fred. Zwarts" <F.Zwarts@KVI.nl> - 2020-01-28 11:45 +0100
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-27 16:31 +1300
Re: two's complement idea Manfred <noname@add.invalid> - 2020-01-26 18:50 +0100
Re: two's complement idea Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-26 18:57 +0000
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-26 20:46 +0100
Re: two's complement idea Robert Wessel <robertwessel2@yahoo.com> - 2020-01-26 13:14 -0600
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-26 22:15 +0100
Re: two's complement idea Robert Wessel <robertwessel2@yahoo.com> - 2020-01-27 21:06 -0600
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-28 13:08 +0100
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-27 01:50 -0800
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-27 08:21 +1300
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-25 20:14 +0100
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-25 20:12 +0100
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-27 07:48 -0800
Re: two's complement idea Bonita Montero <Bonita.Montero@gmail.com> - 2020-02-18 18:46 +0100
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-01-27 01:28 -0800 |
| Message-ID | <864kwhi6yl.fsf@linuxsc.com> |
| In reply to | #71579 |
Ian Collins <ian-news@hotmail.com> writes: > You can misuse any idiom to write bad code. With goto, bad code > comes naturally. I think this implication goes mainly in the other direction. People who use goto aren't generally prone to write bad code; it depends a lot on the person. But people who write bad code are much more likely to use (and misuse) goto than people who don't.
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2020-01-25 22:22 +0000 |
| Message-ID | <slrnr2pftn.km3.grahn+nntp@frailea.sa.invalid> |
| In reply to | #71577 |
On Sat, 2020-01-25, Bart wrote: > On 25/01/2020 18:45, Ian Collins wrote: >> On 26/01/2020 00:57, Bart wrote: >>> On 25/01/2020 06:50, Ian Collins wrote: >>>> On 25/01/2020 14:19, Bart wrote: >>>> >>>>> I can only repeat that the Linux kernel seems to use a lot, about >>>>> 163,000 gotos in 25Mloc (including headers) or 19Mloc (.c files only). >>>>> >>>>> That's a frequency of once every 152 or 117 lines. >>>> >>>> That's also C. >>> >>> David Brown said: >>> >>> "I can only ever remember /once/ using "goto" in C code..." >> >> You asked the question, which you have snipped: "Or C++; as I said >> earlier, it's not clear how much C++ helps avoiding gotos compared with C." >> >> What do you have to say about my answer? >> > > If DB can avoid using 'goto' in C for (I understand) several decades, > then he can do it for C++ too. > > The purpose of my mentioning Linux sources is that there are a range of > programming styles even in C: Linux kernel may be a prolific user of > gotos, DB is at the other end of the scale, and I would say extreme I haven't used them either. I don't think most people consider that extreme, except in that very literal sense. In one C project I was in, someone suggested we could use the "goto error" pattern as seen in the Linux kernel. Everyone accepted the idea, but I don't think we ever did it. That's the last time I heard about goto in real life, except jokingly. But I mostly work in C++ nowadays. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2020-01-25 18:24 -0500 |
| Message-ID | <r0iio9$7lm$1@dont-email.me> |
| In reply to | #71582 |
On 1/25/20 5:22 PM, Jorgen Grahn wrote: ... > I haven't used them either. I don't think most people consider that > extreme, except in that very literal sense. I can't remember ever having used a goto in more than 3 decades of writing C, and somewhat less time writing C++.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-01-26 12:54 +0100 |
| Message-ID | <r0jumc$p8e$1@dont-email.me> |
| In reply to | #71577 |
On 25/01/2020 20:56, Bart wrote:
> On 25/01/2020 18:45, Ian Collins wrote:
>> On 26/01/2020 00:57, Bart wrote:
>>> On 25/01/2020 06:50, Ian Collins wrote:
>>>> On 25/01/2020 14:19, Bart wrote:
>>>>
>>>>> I can only repeat that the Linux kernel seems to use a lot, about
>>>>> 163,000 gotos in 25Mloc (including headers) or 19Mloc (.c files only).
>>>>>
>>>>> That's a frequency of once every 152 or 117 lines.
>>>>
>>>> That's also C.
>>>
>>> David Brown said:
>>>
>>> "I can only ever remember /once/ using "goto" in C code..."
>>
>> You asked the question, which you have snipped: "Or C++; as I said
>> earlier, it's not clear how much C++ helps avoiding gotos compared
>> with C."
>>
>> What do you have to say about my answer?
>>
>
> If DB can avoid using 'goto' in C for (I understand) several decades,
> then he can do it for C++ too.
>
Let's be clear here. I "avoid using goto in C" in the same sense as I
avoid writing 2000 line functions, avoid using variable names in
Swahili, and avoid 8 layers of nested indentation.
You make it sound like my code - being C - should naturally contain
gotos, and I then go to extraordinary efforts to remove the gotos. I
don't. They were never there. I structure my code - gotos do not occur
in structured code. They occur only when you try to use a code
structure that does not match the structure of the task.
> The purpose of my mentioning Linux sources is that there are a range of
> programming styles even in C: Linux kernel may be a prolific user of
> gotos, DB is at the other end of the scale, and I would say extreme
> (actually you can't be more extreme without using a negative number of
> gotos!).
I am "extreme" in the same way that people who don't eat Brussels
sprouts are extreme. I don't find "goto" useful in the coding I do, and
I think any attempt to use it would make my code worse. So I don't use
it. If I thought it would make my code better, I /would/ use it.
>
> I'm not convinced that C++ features such RAII, exceptions, destructors
> and so on are enough to deal with all the use-cases of goto I listed
> earlier in the sub-thread, or the ones I didn't think of.
RAII certainly deals with many possible cases where you think goto is a
good idea. Your other cases can usually be handled by other methods,
whether in C or C++. Often I think the answer is to view the first code
as a prototype or proof of concept that was gradually built while
understanding the task at hand. Now that you understand it, scrap the
code and write new code to handle the task. Trying to "remove gotos"
while leaving everything else untouched is rarely the best solution.
I am also willing to accept that for some of the code you write, "goto"
might be the best choice. Certainly if you take as written all your
other coding preferences (huge files, minimal locality, old C, no
pre-processor, minimal types, etc.), then it would not surprise me to
hear that "goto" fits nicely. I can't comprehend why you have picked
these rules, but they are your choices - and if goto is a good fit with
them, then it makes perfect sense to use it. But accept that other
people have different sets of rules, and "goto" never (or almost never)
enters the picture.
One type of C coding where "goto" is common - and regularly the right
solution - is code generated automatically, such as from language
translators. I doubt if anyone will want to take that use of goto away
from you, whether the code is in C or C++.
>
> So they cannot by themselves account for using for being able to use 0
> gotos. It seems some people just don't like them, and go to extra
> measures to avoid them. Note the word 'extra'.
>
No, you fail to understand. We are not suggesting going to extra effort
to remove "goto". I am suggesting not wasting effort putting in "goto"
in the first place - it was never there in the first place. Ian is
suggesting less effort in later maintenance and adaption of the code by
removing "goto" (presumably as part of other refactoring work, rather
than as a goal in itself). Writing clearer and higher quality code
saves effort overall, even if it appears to take more short-term effort.
> BTW C, and by extension C++, contains flow control that IMO can be even
> worse that goto when abused.
Yes - and no one is recommending them either. (C++ restricts some kinds
of flow that are allowed in C.)
> Takes this code:
>
> int a=1;
>
> goto L;
> if (a) {
> puts("A");
> } else {
> L:
> puts("B");
> }
>
> This should print "A", but because of the jump into the block, will show
> "B". This is considered bad form. But you can do exactly the same
> without the goto:
>
> int a=1;
>
> switch (1) // any value can be used
> if (a) {
> puts("A");
> } else {
> default:
> puts("B");
> }
>
> Should unstructured switch statements like this be banned?
Yes, obviously.
> Well, that's
> not possible; people still need to use switch, and they will also come
> up with use-cases for weird applications of it.
Most C and C++ programmers use switch statements as though it were
strongly structured - they don't mix it with gotos, loops, conditionals,
etc., in a non-structured way. (There is no need to show examples of
exceptions.)
>
> With goto, at least, you know that some underhand flow control is going on!
Use brackets and indentation well, and it is entirely clear when
underhand flow control is going on with switch too.
Divide up your code into smaller sections and functions, and it is
entirely clear that underhand flow control /can't/ be going on.
(The exception, perhaps, is C++ exceptions - these have been called
"hidden goto's" by some. Done well, C++ exceptions can be a very good
thing for program structure - done badly, they can be a very bad thing.)
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-01-26 12:44 +0000 |
| Message-ID | <mQfXF.125675$Bf2.15315@fx39.am4> |
| In reply to | #71590 |
On 26/01/2020 11:54, David Brown wrote: > On 25/01/2020 20:56, Bart wrote: > Let's be clear here. I "avoid using goto in C" in the same sense as I > avoid writing 2000 line functions, avoid using variable names in > Swahili, and avoid 8 layers of nested indentation. > > You make it sound like my code - being C - should naturally contain > gotos, and I then go to extraordinary efforts to remove the gotos. I > don't. They were never there. I structure my code - gotos do not occur > in structured code. They occur only when you try to use a code > structure that does not match the structure of the task. No, the use-cases for goto are always there: common code in a function, nested loop control, usual code flow (plus the temporary uses during development which ought to be eventually removed but which doesn't always happen). I don't know how /you/ get around those, except by preempting those situations, which to me sounds like premature refactorisation. (It's not as though my own code is bristling with gotos. Average incidence is 1 per 4-500 lines. Here, in this rare example of manually written C, there is one per 800 lines: https://github.com/sal55/langs/blob/master/bignum.c https://github.com/sal55/langs/blob/master/bignum.h (No macros either in that project.) The first one ought to be an extra loop (the sort that executes either once, or twice), but I left like that as I thought it was clearer. The second is for a nested loop exit, since the program was hand-ported from my own language, where those 1600 lines of code have only the one goto. >> The purpose of my mentioning Linux sources is that there are a range >> of programming styles even in C: Linux kernel may be a prolific user >> of gotos, DB is at the other end of the scale, and I would say extreme >> (actually you can't be more extreme without using a negative number of >> gotos!). > > I am "extreme" in the same way that people who don't eat Brussels > sprouts are extreme. I don't find "goto" useful in the coding I do, and > I think any attempt to use it would make my code worse. So do I; when I use 'goto', I feel bad about it. But not bad enough to write more elaborate code to eliminate it, because /that/ would make it worse. I might, however, think of a language features to eliminate that use-case. Yesterday I looked at one 5000-line module (not C), which had 4 gotos. I identified one that ought to have been replaced by a loop control statement (to restart a loop; you don't have that in C). The other 3 could be replaced by the 'recase' feature I mentioned yesterday, but which hasn't yet been rolled out to this language. So I'm doing something about it, but in ways that make the code simpler and clearer, not longer and with extra bits. > I am also willing to accept that for some of the code you write, "goto" > might be the best choice. Certainly if you take as written all your > other coding preferences (huge files, minimal locality, old C, no > pre-processor, minimal types, etc.), (I don't write huge files. What you have in mind are the monolithic generated-C files that I've used for distribution, or possibly the amalgamated original-source files, also generated, used to simplify transmission (eg. upload to github or copy to an RPi via a memory-stick). The average module size of my original source is around 1000 lines.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-01-26 14:58 +0100 |
| Message-ID | <r0k5um$375$1@dont-email.me> |
| In reply to | #71591 |
On 26/01/2020 13:44, Bart wrote: > On 26/01/2020 11:54, David Brown wrote: >> On 25/01/2020 20:56, Bart wrote: > >> Let's be clear here. I "avoid using goto in C" in the same sense as I >> avoid writing 2000 line functions, avoid using variable names in >> Swahili, and avoid 8 layers of nested indentation. >> >> You make it sound like my code - being C - should naturally contain >> gotos, and I then go to extraordinary efforts to remove the gotos. I >> don't. They were never there. I structure my code - gotos do not >> occur in structured code. They occur only when you try to use a code >> structure that does not match the structure of the task. > > No, the use-cases for goto are always there: No, they are not. > common code in a function, There are lots of ways to handle common code. I've never felt "goto" to be a good way. (That doesn't mean I don't think it can't occur - merely that I don't think it is often a good way, and I've never felt its need in my own code.) > nested loop control, Gotos are most certainly not needed for that. Again, I'd suggest that if you think "goto" is necessary (in manually written code) to handle the flow you need, then your code structure is probably not ideal. And if you think it is the only efficient solution because extra tests, duplicated calculations, local flag variables, etc., would have a run-time cost, then you are not using the right tools or not using them in the right way. Either efficiency doesn't matter, so the cost is irrelevant, or you use good tools and let the compiler handle the optimisation from flags to gotos. It is very rare that you need maximal code efficiency and have no choice but to use poor tools. > usual code flow "goto" is not part of the usual code flow in any structured programming. It is, at most, for very /unusual/ code flow requirements. > (plus the temporary uses during > development which ought to be eventually removed but which doesn't > always happen). If it ought to be removed, it ought to be removed. "I should have done this but I didn't" is hardly an excuse! And again, this shows your misunderstanding. Avoiding goto is not about /removing/ gotos from code you write - it is about not writing "goto" in the first place. And avoiding goto is not the aim in itself - avoiding unstructured coding is the aim (which itself is a consequence of the higher aim of writing clear, legible and maintainable code). > > I don't know how /you/ get around those, except by preempting those > situations, which to me sounds like premature refactorisation. I don't get myself into those situations. My first programming language was BASIC, but I moved on to structured coding. (And even in my BASIC programming, I preferred structured BASICs.) > > (It's not as though my own code is bristling with gotos. Average > incidence is 1 per 4-500 lines. Here, in this rare example of manually > written C, there is one per 800 lines: > > https://github.com/sal55/langs/blob/master/bignum.c > https://github.com/sal55/langs/blob/master/bignum.h > You don't use goto much, yet you think it is inconceivable that others don't use it at all? > (No macros either in that project.) Only you consider that a good thing. > > The first one ought to be an extra loop (the sort that executes either > once, or twice), but I left like that as I thought it was clearer. > > The second is for a nested loop exit, since the program was hand-ported > from my own language, where those 1600 lines of code have only the one > goto. I haven't looked at your code. But I have already mentioned that automated code generation and translation into C may be /good/ reasons for using goto. The same would apply (but to a lesser extent) when you are trying to do manual literal translations from another language to C. Literal translations rarely end up with good quality code as the result. > > >>> The purpose of my mentioning Linux sources is that there are a range >>> of programming styles even in C: Linux kernel may be a prolific user >>> of gotos, DB is at the other end of the scale, and I would say >>> extreme (actually you can't be more extreme without using a negative >>> number of gotos!). >> >> I am "extreme" in the same way that people who don't eat Brussels >> sprouts are extreme. I don't find "goto" useful in the coding I do, >> and I think any attempt to use it would make my code worse. > > So do I; when I use 'goto', I feel bad about it. But not bad enough to > write more elaborate code to eliminate it, because /that/ would make it > worse. I might, however, think of a language features to eliminate that > use-case. > I don't avoid goto because it makes me feel bad - I avoid bad coding because it is bad coding. That naturally results in negligible use of goto, because goto has negligible use in good coding. And C has plenty of ways to write code well (leading, of course, to plenty of ways to write code badly) - it doesn't need more. If I want more ways to write code, I use a different language (like C++). And while C++ certainly has improved by making it easier to structure code in different ways, none of these has been with the aim of "avoiding goto". > Yesterday I looked at one 5000-line module (not C), which had 4 gotos. I > identified one that ought to have been replaced by a loop control > statement (to restart a loop; you don't have that in C). The other 3 > could be replaced by the 'recase' feature I mentioned yesterday, but > which hasn't yet been rolled out to this language. > > So I'm doing something about it, but in ways that make the code simpler > and clearer, not longer and with extra bits. > >> I am also willing to accept that for some of the code you write, >> "goto" might be the best choice. Certainly if you take as written all >> your other coding preferences (huge files, minimal locality, old C, no >> pre-processor, minimal types, etc.), > > (I don't write huge files. What you have in mind are the monolithic > generated-C files that I've used for distribution, or possibly the > amalgamated original-source files, also generated, used to simplify > transmission (eg. upload to github or copy to an RPi via a memory-stick). > > The average module size of my original source is around 1000 lines.) >
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-01-26 14:53 +0000 |
| Message-ID | <%JhXF.102988$%G5.101221@fx03.am4> |
| In reply to | #71592 |
On 26/01/2020 13:58, David Brown wrote: > On 26/01/2020 13:44, Bart wrote: >> On 26/01/2020 11:54, David Brown wrote: >>> On 25/01/2020 20:56, Bart wrote: >> >>> Let's be clear here. I "avoid using goto in C" in the same sense as >>> I avoid writing 2000 line functions, avoid using variable names in >>> Swahili, and avoid 8 layers of nested indentation. >>> >>> You make it sound like my code - being C - should naturally contain >>> gotos, and I then go to extraordinary efforts to remove the gotos. I >>> don't. They were never there. I structure my code - gotos do not >>> occur in structured code. They occur only when you try to use a code >>> structure that does not match the structure of the task. >> >> No, the use-cases for goto are always there: > > No, they are not. > >> common code in a function, > > There are lots of ways to handle common code. I've never felt "goto" to > be a good way. (That doesn't mean I don't think it can't occur - merely > that I don't think it is often a good way, and I've never felt its need > in my own code.) > > >> nested loop control, > > Gotos are most certainly not needed for that. > > Again, I'd suggest that if you think "goto" is necessary (in manually > written code) to handle the flow you need, then your code structure is > probably not ideal. Do you ever use loop 'break' in your code? Because some consider that impure too. If so, what would you feel about someone claiming they have never ever used 'break' in their C or C++ code? (I can't easily distinguish loop-break from switch-break in source. However, I've got my C compiler to help out and that tells me that the 235Kloc sqlite3.c + shell.c program contains: 645 gotos 300 loop-breaks 800 switch-breaks Interesting that there are 800 useless switch-breaks that nobody objects to (where omitting one is an undetectable bug), more than the number of universally hated gotos. Anyway, loop-break is extensively used here.) > >> usual code flow > > "goto" is not part of the usual code flow in any structured programming. > It is, at most, for very /unusual/ code flow requirements. I meant 'unusual'. > >> (plus the temporary uses during development which ought to be >> eventually removed but which doesn't always happen). > > If it ought to be removed, it ought to be removed. "I should have done > this but I didn't" is hardly an excuse! Because it's working code. Removing goto would be disruptive and introduce bugs. > And again, this shows your misunderstanding. Avoiding goto is not about > /removing/ gotos from code you write - it is about not writing "goto" in > the first place. And avoiding goto is not the aim in itself - avoiding > unstructured coding is the aim (which itself is a consequence of the > higher aim of writing clear, legible and maintainable code). The next level or two beyond structured code is functional programming. And we all know how legible that can be. >> (No macros either in that project.) > > Only you consider that a good thing. Yes; most uses of macros in C I consider a failing in the language. (However, I've since introduced parametric macros for the first time in my own languages. AST-based not token-based like C, so more restrictive (they have to result in a well-formed expression). The feature is still experimental.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-01-26 19:10 +0100 |
| Message-ID | <r0kkn9$t6q$1@dont-email.me> |
| In reply to | #71596 |
On 26/01/2020 15:53, Bart wrote: > On 26/01/2020 13:58, David Brown wrote: >> On 26/01/2020 13:44, Bart wrote: >>> On 26/01/2020 11:54, David Brown wrote: >>>> On 25/01/2020 20:56, Bart wrote: >>> >>>> Let's be clear here. I "avoid using goto in C" in the same sense as >>>> I avoid writing 2000 line functions, avoid using variable names in >>>> Swahili, and avoid 8 layers of nested indentation. >>>> >>>> You make it sound like my code - being C - should naturally contain >>>> gotos, and I then go to extraordinary efforts to remove the gotos. >>>> I don't. They were never there. I structure my code - gotos do not >>>> occur in structured code. They occur only when you try to use a >>>> code structure that does not match the structure of the task. >>> >>> No, the use-cases for goto are always there: >> >> No, they are not. >> >>> common code in a function, >> >> There are lots of ways to handle common code. I've never felt "goto" >> to be a good way. (That doesn't mean I don't think it can't occur - >> merely that I don't think it is often a good way, and I've never felt >> its need in my own code.) >> >> >>> nested loop control, >> >> Gotos are most certainly not needed for that. >> >> Again, I'd suggest that if you think "goto" is necessary (in manually >> written code) to handle the flow you need, then your code structure is >> probably not ideal. > > Do you ever use loop 'break' in your code? Because some consider that > impure too. I do use "break", yes. (I rarely find use for "continue".) I also am happy with multiple "return" points in a function. Early returns based on parameter values are typically, I think, simpler and clearer than adding new layers of "if" statements or extra functions. I am more cautious about extra returns in the middle of a function - it has to be clear why it is happening. Exiting multiple loops early is an example of such cases. Here, the "early return" means a new way to exit the function, but unlike using "goto" it avoids extra entry points to other parts of the function. (I am aware that some people disapprove of "break" or "continue" in loops, and any "return" except as the last line of a function.) As well as readability and maintainability of code, this is all about keeping control of the number of paths through the function, and its cyclomatic complexity. If you want to be sure that a function will work, you need to know all the possible paths through it. You need to know all the loops - and be sure you can guarantee progress towards an end result. Jumping around makes this massively more difficult. > > If so, what would you feel about someone claiming they have never ever > used 'break' in their C or C++ code? > (I assume you are meaning "break" from loops here, and not in switch statements.) I would believe someone who claimed this, yes. People have different styles, and different needs in their coding. > (I can't easily distinguish loop-break from switch-break in source. > However, I've got my C compiler to help out and that tells me that the > 235Kloc sqlite3.c + shell.c program contains: > > 645 gotos > 300 loop-breaks > 800 switch-breaks > > Interesting that there are 800 useless switch-breaks that nobody objects > to (where omitting one is an undetectable bug), more than the number of > universally hated gotos. Anyway, loop-break is extensively used here.) > Why do you think no one objects to having to put "break" in switch cases? I suspect that the solid majority of C programmers would have been happier if switch statements were properly structured with respect to the rest of the language, with cases starting new blocks (and therefore no need for "break"). As a second-best choice, most would prefer that cases functioned as though they had "break" at the end, and you needed an explicit "fall-through" indicator (you'd need a nice way of having multiple cases). People will tell you that they have no problem using switch in C and C++, and that their compiler tells them if they forget a "break", and perhaps they will tell you /why/ C has switch the way it does. Do not mistake that for thinking they prefer it that way or think it would be a good way to design a "switch" statement in a modern language. Also, do not imagine that goto is universally hated. It is often decried, but not universally. And people who have expressed an opinion here do not (I think) actively goto for its own sake - they avoid the kind of code structures in which "goto" might seem a feasible solution. >> >>> usual code flow >> >> "goto" is not part of the usual code flow in any structured >> programming. It is, at most, for very /unusual/ code flow requirements. > > I meant 'unusual'. Fair enough. I always aim for /usual/ code flow - code should flow in the way people expect. > >> >>> (plus the temporary uses during development which ought to be >>> eventually removed but which doesn't always happen). >> >> If it ought to be removed, it ought to be removed. "I should have >> done this but I didn't" is hardly an excuse! > > Because it's working code. Removing goto would be disruptive and > introduce bugs. That sounds like a flawed development methodology. Some code is "write and forget", and its quality and future maintainability does not matter. But for most serious code, the code is not ready until it is clear and complete, where you can honestly say "I did a good job on that code" as you check it in to the project. You know that you - or anyone else - can take the code later, understand what it does, change it, re-use it, without a risk of mistakes, without spending hours figuring out what it does and how it does it. It is not enough that code works - it must be clear that it is correct. That is how you write /robust/ code. What you are describing is "fragile" code - code that other programmers (including your future self) are afraid to touch because it could easily break. Now, many people /do/ write fragile code. It may even be most people. And many managers and project leaders are only interested in short-term costs and place little emphasis on long-term reliability and usability of code, leading to "it passed the test, ship it and we're done" mentality. (Note - this is /not/ "test-driven development".) The result is vast wastage overall. <https://dilbert.com/strip/2014-08-12> > >> And again, this shows your misunderstanding. Avoiding goto is not >> about /removing/ gotos from code you write - it is about not writing >> "goto" in the first place. And avoiding goto is not the aim in itself >> - avoiding unstructured coding is the aim (which itself is a >> consequence of the higher aim of writing clear, legible and >> maintainable code). > > The next level or two beyond structured code is functional programming. I was talking about goals for development, not levels of programming language. And no, there is not really a hierarchy of programming languages like this that puts "functional programming" one or two levels above "structured programming". They are orthogonal concepts. You might have more of a point if you were comparing functional programming with imperative programming, but really there is no clear distinction or ordering. > And we all know how legible that can be. Functional programming can be very legible. It is just a little fussier about who its readers are. For example, this is a functional programming quicksort function (based on a Haskell example on Wikipedia): quicksort [] = [] quicksort (pivot : tail) = quicksort [x | x <- tail, x < pivot] ++ [pivot] ++ quicksort [x | x <- tail, x > pivot] Are you going to tell me that this is hard to follow, even if you have never seen Haskell before? The Python equivalent would be: def quicksort(data) : if data == [] : return [] pivot, tail = data[0], data[1:] return quicksort([x for x in tail if x < pivot]) + [pivot] + quicksort([x for x in tail if x > pivot]) That is Python code written in a functional programming style. Do you find that illegible? (Of course a lot of functional programming code will be hard to understand if you are unfamiliar with the language and style. The same applies to most languages.) > >>> (No macros either in that project.) >> >> Only you consider that a good thing. > > Yes; most uses of macros in C I consider a failing in the language. > That is a non-sequitor. C is a programming language - it is specified in standards, implemented by compilers. It has its limitations and its questionable design decisions (especially seen with modern eyes), as do all languages. There are certainly things that are often done using C macros that could be better done with other features in other languages (C++ provides features that replace many uses of macros in C). But given that a programmer is writing in C, it makes sense to use macros whenever they are appropriate for the aims of the task. > (However, I've since introduced parametric macros for the first time in > my own languages. AST-based not token-based like C, so more restrictive > (they have to result in a well-formed expression). The feature is still > experimental.) >
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2020-01-26 13:20 -0600 |
| Message-ID | <49pr2fphchn3dk2hiqv2bk8ml5oijs0d6e@4ax.com> |
| In reply to | #71598 |
On Sun, 26 Jan 2020 19:10:47 +0100, David Brown <david.brown@hesbynett.no> wrote: >On 26/01/2020 15:53, Bart wrote: >> Do you ever use loop 'break' in your code? Because some consider that >> impure too. > >I do use "break", yes. (I rarely find use for "continue".) I also am >happy with multiple "return" points in a function. Early returns based >on parameter values are typically, I think, simpler and clearer than >adding new layers of "if" statements or extra functions. I am more >cautious about extra returns in the middle of a function - it has to be >clear why it is happening. Exiting multiple loops early is an example >of such cases. Here, the "early return" means a new way to exit the >function, but unlike using "goto" it avoids extra entry points to other >parts of the function. > >(I am aware that some people disapprove of "break" or "continue" in >loops, and any "return" except as the last line of a function.) I'd point out that the justification for a multi-level break (or continue) is exactly the same as for an early return - avoiding those extra layers of ifs, state variables or functions just to implement the control flow. I think C should have such a feature*, but it doesn't. A goto can simulate that pretty well. Again, something to be used sparingly. *Allow a break or continue to reference a label attached to a loop or switch.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-01-26 20:51 +0000 |
| Message-ID | <DZmXF.242725$_R5.99089@fx19.am4> |
| In reply to | #71601 |
On 26/01/2020 19:20, Robert Wessel wrote:
> On Sun, 26 Jan 2020 19:10:47 +0100, David Brown
> <david.brown@hesbynett.no> wrote:
>
>> On 26/01/2020 15:53, Bart wrote:
>
>>> Do you ever use loop 'break' in your code? Because some consider that
>>> impure too.
>>
>> I do use "break", yes. (I rarely find use for "continue".) I also am
>> happy with multiple "return" points in a function. Early returns based
>> on parameter values are typically, I think, simpler and clearer than
>> adding new layers of "if" statements or extra functions. I am more
>> cautious about extra returns in the middle of a function - it has to be
>> clear why it is happening. Exiting multiple loops early is an example
>> of such cases. Here, the "early return" means a new way to exit the
>> function, but unlike using "goto" it avoids extra entry points to other
>> parts of the function.
>>
>> (I am aware that some people disapprove of "break" or "continue" in
>> loops, and any "return" except as the last line of a function.)
>
>
> I'd point out that the justification for a multi-level break (or
> continue) is exactly the same as for an early return - avoiding those
> extra layers of ifs, state variables or functions just to implement
> the control flow. I think C should have such a feature*, but it
> doesn't. A goto can simulate that pretty well.
>
> Again, something to be used sparingly.
>
>
> *Allow a break or continue to reference a label attached to a loop or
> switch.
>
I've implemented multi-level breaks (and a couple of other loop controls
you don't find in C and C++).
If the inner loops are numbered from 1 (where the break statement is) to
N (outermost loop), then you write the equivalent of:
break; // or break 1
break 2 // next outer loop
break N; // break out of all loops
Not everyone likes applying an index like this (eg. you add or remove
loops, and the numbers have to change); they prefer labeled statements.
However I've found the most common requirement (other than the
inner-most) is to break out of all loops. So I have a special form:
break all;
(Which is exactly the same as break 0, is a synonym for N.)
No indexing needed nor any labeling. And you can wrap extra inner loops
around the break statement without having to change anything.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2020-01-26 21:02 -0600 |
| Message-ID | <p3ks2f1vekfr0dckvguuvkrdr6lrpedrsl@4ax.com> |
| In reply to | #71604 |
On Sun, 26 Jan 2020 20:51:46 +0000, Bart <bc@freeuk.com> wrote: >On 26/01/2020 19:20, Robert Wessel wrote: >> On Sun, 26 Jan 2020 19:10:47 +0100, David Brown >> <david.brown@hesbynett.no> wrote: >> >>> On 26/01/2020 15:53, Bart wrote: >> >>>> Do you ever use loop 'break' in your code? Because some consider that >>>> impure too. >>> >>> I do use "break", yes. (I rarely find use for "continue".) I also am >>> happy with multiple "return" points in a function. Early returns based >>> on parameter values are typically, I think, simpler and clearer than >>> adding new layers of "if" statements or extra functions. I am more >>> cautious about extra returns in the middle of a function - it has to be >>> clear why it is happening. Exiting multiple loops early is an example >>> of such cases. Here, the "early return" means a new way to exit the >>> function, but unlike using "goto" it avoids extra entry points to other >>> parts of the function. >>> >>> (I am aware that some people disapprove of "break" or "continue" in >>> loops, and any "return" except as the last line of a function.) >> >> >> I'd point out that the justification for a multi-level break (or >> continue) is exactly the same as for an early return - avoiding those >> extra layers of ifs, state variables or functions just to implement >> the control flow. I think C should have such a feature*, but it >> doesn't. A goto can simulate that pretty well. >> >> Again, something to be used sparingly. >> >> >> *Allow a break or continue to reference a label attached to a loop or >> switch. >> > >I've implemented multi-level breaks (and a couple of other loop controls >you don't find in C and C++). > >If the inner loops are numbered from 1 (where the break statement is) to >N (outermost loop), then you write the equivalent of: > > break; // or break 1 > break 2 // next outer loop > break N; // break out of all loops > >Not everyone likes applying an index like this (eg. you add or remove >loops, and the numbers have to change); they prefer labeled statements. > >However I've found the most common requirement (other than the >inner-most) is to break out of all loops. So I have a special form: > > break all; > >(Which is exactly the same as break 0, is a synonym for N.) > >No indexing needed nor any labeling. And you can wrap extra inner loops >around the break statement without having to change anything. I like the labeled approach. The problem with the "level" approach is that the insertion or deletion of a loop/switch in the hierarchy would normally not change where you wanted to break to, but if you've specified the break with a level, you *will* suddenly be breaking to a different loop. The label makes the association with the loop/switch of interest explicit. I view the issue as similar to that of significant white space for flow control (as in Python). A small advantage is that a meaningful label can provide documentation. This isn't something that's going to have massive numbers of uses, so I don't thing the slight advantage of brevity the level approach has is meaningful. Neither approach breaks any existing valid code.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-01-26 19:06 -0800 |
| Message-ID | <87blqp4myy.fsf@nosuchdomain.example.com> |
| In reply to | #71608 |
Robert Wessel <robertwessel2@yahoo.com> writes:
> On Sun, 26 Jan 2020 20:51:46 +0000, Bart <bc@freeuk.com> wrote:
[...]
>>If the inner loops are numbered from 1 (where the break statement is) to
>>N (outermost loop), then you write the equivalent of:
>>
>> break; // or break 1
>> break 2 // next outer loop
>> break N; // break out of all loops
>>
>>Not everyone likes applying an index like this (eg. you add or remove
>>loops, and the numbers have to change); they prefer labeled statements.
[...]
> I like the labeled approach. The problem with the "level" approach is
> that the insertion or deletion of a loop/switch in the hierarchy would
> normally not change where you wanted to break to, but if you've
> specified the break with a level, you *will* suddenly be breaking to a
> different loop. The label makes the association with the loop/switch
> of interest explicit.
[...]
My objection to the "break 2" approach is that it requires humans to
count things. Computers are really really good at counting things.
Let them.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-01-27 18:50 +0000 |
| Message-ID | <VhGXF.46342$BA5.20568@fx21.am4> |
| In reply to | #71608 |
On 27/01/2020 03:02, Robert Wessel wrote:
> On Sun, 26 Jan 2020 20:51:46 +0000, Bart <bc@freeuk.com> wrote:
>> I've implemented multi-level breaks (and a couple of other loop controls
>> you don't find in C and C++).
>>
>> If the inner loops are numbered from 1 (where the break statement is) to
>> N (outermost loop), then you write the equivalent of:
>>
>> break; // or break 1
>> break 2 // next outer loop
>> break N; // break out of all loops
>>
>> Not everyone likes applying an index like this (eg. you add or remove
>> loops, and the numbers have to change); they prefer labeled statements.
>>
>> However I've found the most common requirement (other than the
>> inner-most) is to break out of all loops. So I have a special form:
>>
>> break all;
> I like the labeled approach. The problem with the "level" approach is
> that the insertion or deletion of a loop/switch in the hierarchy would
> normally not change where you wanted to break to, but if you've
> specified the break with a level, you *will* suddenly be breaking to a
> different loop.
Yes, I stated that is the problem (more long-windedly than intended).
I also said that most of the time you want to break out of an outer loop
from an inner one, it will be the outermost one. So it doesn't need
identifying with an index or label.
> The label makes the association with the loop/switch
> of interest explicit. I view the issue as similar to that of
> significant white space for flow control (as in Python). A small
> advantage is that a meaningful label can provide documentation.
Any label is going to be similar to a goto label (possibly, identical).
That makes:
break L;
...
}
}
L: // or maybe the label is at the beginning
not that different to:
goto L;
...
}
}
L:
(Problem using a regular label is that you have to search the code to
see if you get there from goto, break, or both.)
> This isn't something that's going to have massive numbers of uses, so
> I don't thing the slight advantage of brevity the level approach has
> is meaningful.
In my programs, 1-3% of loop controls are nested. But when you do need
it, it can save time trying to code around what you really want to.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2020-01-27 14:18 -0600 |
| Message-ID | <e1hu2f5p960nhg1spsvndon031nop7ldhr@4ax.com> |
| In reply to | #71627 |
On Mon, 27 Jan 2020 18:50:28 +0000, Bart <bc@freeuk.com> wrote:
>On 27/01/2020 03:02, Robert Wessel wrote:
>> On Sun, 26 Jan 2020 20:51:46 +0000, Bart <bc@freeuk.com> wrote:
>
>>> I've implemented multi-level breaks (and a couple of other loop controls
>>> you don't find in C and C++).
>>>
>>> If the inner loops are numbered from 1 (where the break statement is) to
>>> N (outermost loop), then you write the equivalent of:
>>>
>>> break; // or break 1
>>> break 2 // next outer loop
>>> break N; // break out of all loops
>>>
>>> Not everyone likes applying an index like this (eg. you add or remove
>>> loops, and the numbers have to change); they prefer labeled statements.
>>>
>>> However I've found the most common requirement (other than the
>>> inner-most) is to break out of all loops. So I have a special form:
>>>
>>> break all;
>
>> I like the labeled approach. The problem with the "level" approach is
>> that the insertion or deletion of a loop/switch in the hierarchy would
>> normally not change where you wanted to break to, but if you've
>> specified the break with a level, you *will* suddenly be breaking to a
>> different loop.
>
>Yes, I stated that is the problem (more long-windedly than intended).
>
>I also said that most of the time you want to break out of an outer loop
>from an inner one, it will be the outermost one. So it doesn't need
>identifying with an index or label.
>
>> The label makes the association with the loop/switch
>> of interest explicit. I view the issue as similar to that of
>> significant white space for flow control (as in Python). A small
>> advantage is that a meaningful label can provide documentation.
>
>Any label is going to be similar to a goto label (possibly, identical).
>
>That makes:
>
> break L;
> ...
> }
> }
>L: // or maybe the label is at the beginning
>
>not that different to:
>
> goto L;
> ...
> }
> }
>L:
>
>(Problem using a regular label is that you have to search the code to
>see if you get there from goto, break, or both.)
No the labels would be on the loop/switch statement. So:
outerloop: for(...)
{
for(...)
{
...
if (...)
break outerloop;
...
}
}
That has two advantages - the label actually refers to the loop (or
switch you're trying to do something with), and second, it's a natural
extension to the language - labels are already (somewhat over
simplified) a prefix on a statement. So valid targets for a
break/continue are just enclosing statements of the right type with a
label.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-01-27 22:13 +0100 |
| Message-ID | <r0njph$86d$1@dont-email.me> |
| In reply to | #71629 |
On 27/01/2020 21:18, Robert Wessel wrote:
> On Mon, 27 Jan 2020 18:50:28 +0000, Bart <bc@freeuk.com> wrote:
>
>> On 27/01/2020 03:02, Robert Wessel wrote:
<snip>
>>> The label makes the association with the loop/switch
>>> of interest explicit. I view the issue as similar to that of
>>> significant white space for flow control (as in Python). A small
>>> advantage is that a meaningful label can provide documentation.
>>
>> Any label is going to be similar to a goto label (possibly, identical).
>>
>> That makes:
>>
>> break L;
>> ...
>> }
>> }
>> L: // or maybe the label is at the beginning
>>
>> not that different to:
>>
>> goto L;
>> ...
>> }
>> }
>> L:
>>
>> (Problem using a regular label is that you have to search the code to
>> see if you get there from goto, break, or both.)
>
>
> No the labels would be on the loop/switch statement. So:
>
> outerloop: for(...)
> {
> for(...)
> {
> ...
> if (...)
> break outerloop;
> ...
> }
> }
>
> That has two advantages - the label actually refers to the loop (or
> switch you're trying to do something with), and second, it's a natural
> extension to the language - labels are already (somewhat over
> simplified) a prefix on a statement. So valid targets for a
> break/continue are just enclosing statements of the right type with a
> label.
>
That strikes me as a neat and clear way to break out of a nested loop.
In particular, it avoids the over-flexibility of goto - you can break
out of a loop, but you can't jump to arbitrary points in the code. And
a label makes it clear what you want to exit.
My preference is still mainly to have loop conditionals that cover all
cases, so breaks (or early returns or other exits) should be rare. But
if you need to break out of a nested loop, this would be a good way to
handle it.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-01-27 21:38 +0000 |
| Message-ID | <oLIXF.113152$%G5.81633@fx03.am4> |
| In reply to | #71630 |
On 27/01/2020 21:13, David Brown wrote:
> On 27/01/2020 21:18, Robert Wessel wrote:
>> On Mon, 27 Jan 2020 18:50:28 +0000, Bart <bc@freeuk.com> wrote:
>>
>>> On 27/01/2020 03:02, Robert Wessel wrote:
>
> <snip>
>
>>>> The label makes the association with the loop/switch
>>>> of interest explicit. I view the issue as similar to that of
>>>> significant white space for flow control (as in Python). A small
>>>> advantage is that a meaningful label can provide documentation.
>>>
>>> Any label is going to be similar to a goto label (possibly, identical).
>>>
>>> That makes:
>>>
>>> break L;
>>> ...
>>> }
>>> }
>>> L: // or maybe the label is at the beginning
>>>
>>> not that different to:
>>>
>>> goto L;
>>> ...
>>> }
>>> }
>>> L:
>>>
>>> (Problem using a regular label is that you have to search the code to
>>> see if you get there from goto, break, or both.)
>>
>>
>> No the labels would be on the loop/switch statement. So:
>>
>> outerloop: for(...)
>> {
>> for(...)
>> {
>> ...
>> if (...)
>> break outerloop;
>> ...
>> }
>> }
>>
>> That has two advantages - the label actually refers to the loop (or
>> switch you're trying to do something with), and second, it's a natural
>> extension to the language - labels are already (somewhat over
>> simplified) a prefix on a statement. So valid targets for a
>> break/continue are just enclosing statements of the right type with a
>> label.
>>
>
> That strikes me as a neat and clear way to break out of a nested loop.
> In particular, it avoids the over-flexibility of goto - you can break
> out of a loop, but you can't jump to arbitrary points in the code. And
> a label makes it clear what you want to exit.
>
I just tried to implement that (in a C compiler), then I realised that
the label I wanted wasn't actually at the start of the loop statement,
but just past the end!
That makes it harder (would have taken longer than the 20 minutes I'd
set aside). And it raises one issue: if this label is also a legal goto
label, then:
outerloop:
for(;;) { while(1) {
goto outerloop;
break outerloop;
}}
// endofouterloop:
the statements will jump to completely different points. The break
actually goes to an implicit statement after the loop.
At this point, it seems to me the following would actually be clearer:
for(;;) { while(1) {
goto endofouterloop;
}}
endofouterloop:
as it pinpoints exactly where the code will end up next. With loads of
nested }s floating around, many nothing to do with the loops, the end of
the desired loop is not always easy to find.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2020-01-27 19:37 -0600 |
| Message-ID | <go3v2f9mpoe2shqdvvakdrp4rb6n9bl6e9@4ax.com> |
| In reply to | #71631 |
On Mon, 27 Jan 2020 21:38:26 +0000, Bart <bc@freeuk.com> wrote:
>On 27/01/2020 21:13, David Brown wrote:
>> On 27/01/2020 21:18, Robert Wessel wrote:
>>> On Mon, 27 Jan 2020 18:50:28 +0000, Bart <bc@freeuk.com> wrote:
>>>
>>>> On 27/01/2020 03:02, Robert Wessel wrote:
>>
>> <snip>
>>
>>>>> The label makes the association with the loop/switch
>>>>> of interest explicit. I view the issue as similar to that of
>>>>> significant white space for flow control (as in Python). A small
>>>>> advantage is that a meaningful label can provide documentation.
>>>>
>>>> Any label is going to be similar to a goto label (possibly, identical).
>>>>
>>>> That makes:
>>>>
>>>> break L;
>>>> ...
>>>> }
>>>> }
>>>> L: // or maybe the label is at the beginning
>>>>
>>>> not that different to:
>>>>
>>>> goto L;
>>>> ...
>>>> }
>>>> }
>>>> L:
>>>>
>>>> (Problem using a regular label is that you have to search the code to
>>>> see if you get there from goto, break, or both.)
>>>
>>>
>>> No the labels would be on the loop/switch statement. So:
>>>
>>> outerloop: for(...)
>>> {
>>> for(...)
>>> {
>>> ...
>>> if (...)
>>> break outerloop;
>>> ...
>>> }
>>> }
>>>
>>> That has two advantages - the label actually refers to the loop (or
>>> switch you're trying to do something with), and second, it's a natural
>>> extension to the language - labels are already (somewhat over
>>> simplified) a prefix on a statement. So valid targets for a
>>> break/continue are just enclosing statements of the right type with a
>>> label.
>>>
>>
>> That strikes me as a neat and clear way to break out of a nested loop.
>> In particular, it avoids the over-flexibility of goto - you can break
>> out of a loop, but you can't jump to arbitrary points in the code. And
>> a label makes it clear what you want to exit.
>>
>
>I just tried to implement that (in a C compiler), then I realised that
>the label I wanted wasn't actually at the start of the loop statement,
>but just past the end!
>
>That makes it harder (would have taken longer than the 20 minutes I'd
>set aside). And it raises one issue: if this label is also a legal goto
>label, then:
>
> outerloop:
> for(;;) { while(1) {
> goto outerloop;
> break outerloop;
> }}
>// endofouterloop:
>
>the statements will jump to completely different points. The break
>actually goes to an implicit statement after the loop.
I think the slight oddity of target location when the label is used
for both a break/continue and a goto is pretty minor. I suppose we
could come up with some alternative way to specify a "statement name",
but I don't see a big advantage. If we can have a dozen meanings of
static, why not this.
>At this point, it seems to me the following would actually be clearer:
>
> for(;;) { while(1) {
> goto endofouterloop;
> }}
> endofouterloop:
>
>as it pinpoints exactly where the code will end up next. With loads of
>nested }s floating around, many nothing to do with the loops, the end of
>the desired loop is not always easy to find.
I think that's the wrong principle. If you want to target a specific
location, use a goto. The idea is to break/continue a loop/switch, so
it should be the *loop/switch* that should be identified.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-01-27 19:15 -0800 |
| Message-ID | <874kwg46fl.fsf@nosuchdomain.example.com> |
| In reply to | #71632 |
Robert Wessel <robertwessel2@yahoo.com> writes:
> On Mon, 27 Jan 2020 21:38:26 +0000, Bart <bc@freeuk.com> wrote:
[...]
>>That makes it harder (would have taken longer than the 20 minutes I'd
>>set aside). And it raises one issue: if this label is also a legal goto
>>label, then:
>>
>> outerloop:
>> for(;;) { while(1) {
>> goto outerloop;
>> break outerloop;
>> }}
>>// endofouterloop:
>>
>>the statements will jump to completely different points. The break
>>actually goes to an implicit statement after the loop.
>
>
> I think the slight oddity of target location when the label is used
> for both a break/continue and a goto is pretty minor. I suppose we
> could come up with some alternative way to specify a "statement name",
> but I don't see a big advantage. If we can have a dozen meanings of
> static, why not this.
>
>>At this point, it seems to me the following would actually be clearer:
>>
>> for(;;) { while(1) {
>> goto endofouterloop;
>> }}
>> endofouterloop:
>>
>>as it pinpoints exactly where the code will end up next. With loads of
>>nested }s floating around, many nothing to do with the loops, the end of
>>the desired loop is not always easy to find.
>
> I think that's the wrong principle. If you want to target a specific
> location, use a goto. The idea is to break/continue a loop/switch, so
> it should be the *loop/switch* that should be identified.
Personally, I like the way Ada does this. You can apply a label to a
loop, and it's the name of the loop ("--" introduces a comment):
OUTER: while condition loop
INNER: while condition loop
-- do stuff
if Done_With_Outer then
exit OUTER; -- "exit" is Ada for "break"
elsif Done_With_Inner then
exit INNER;
end if;
-- do more stuff
end loop INNER;
end loop OUTER;
"exit OUTER" is best thought of as an operation that applies to the loop
named "OUTER" rather than as a branch to a particular location.
Loops that are the targets of goto statements have a different syntax,
one that was designed to stand out:
<<LABEL>>
...
goto LABEL;
On the other hand, Perl does something similar, but uses the same syntax
for loop names and goto labels. This does mean that seeing a named loop
raises the possibility that somewhere there's a goto that targets it,
but that's not much of a problem in practice.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | "Fred. Zwarts" <F.Zwarts@KVI.nl> |
|---|---|
| Date | 2020-01-28 11:45 +0100 |
| Message-ID | <r0p3bl$1dln$1@gioia.aioe.org> |
| In reply to | #71631 |
Op 27.jan..2020 om 22:38 schreef Bart:
> On 27/01/2020 21:13, David Brown wrote:
>> On 27/01/2020 21:18, Robert Wessel wrote:
>>> On Mon, 27 Jan 2020 18:50:28 +0000, Bart <bc@freeuk.com> wrote:
>>>
>>>> On 27/01/2020 03:02, Robert Wessel wrote:
>>
>> <snip>
>>
>>>>> The label makes the association with the loop/switch
>>>>> of interest explicit. I view the issue as similar to that of
>>>>> significant white space for flow control (as in Python). A small
>>>>> advantage is that a meaningful label can provide documentation.
>>>>
>>>> Any label is going to be similar to a goto label (possibly, identical).
>>>>
>>>> That makes:
>>>>
>>>> break L;
>>>> ...
>>>> }
>>>> }
>>>> L: // or maybe the label is at the beginning
>>>>
>>>> not that different to:
>>>>
>>>> goto L;
>>>> ...
>>>> }
>>>> }
>>>> L:
>>>>
>>>> (Problem using a regular label is that you have to search the code to
>>>> see if you get there from goto, break, or both.)
>>>
>>>
>>> No the labels would be on the loop/switch statement. So:
>>>
>>> outerloop: for(...)
>>> {
>>> for(...)
>>> {
>>> ...
>>> if (...)
>>> break outerloop;
>>> ...
>>> }
>>> }
>>>
>>> That has two advantages - the label actually refers to the loop (or
>>> switch you're trying to do something with), and second, it's a natural
>>> extension to the language - labels are already (somewhat over
>>> simplified) a prefix on a statement. So valid targets for a
>>> break/continue are just enclosing statements of the right type with a
>>> label.
>>>
>>
>> That strikes me as a neat and clear way to break out of a nested loop.
>> In particular, it avoids the over-flexibility of goto - you can break
>> out of a loop, but you can't jump to arbitrary points in the code.
>> And a label makes it clear what you want to exit.
>>
>
> I just tried to implement that (in a C compiler), then I realised that
> the label I wanted wasn't actually at the start of the loop statement,
> but just past the end!
>
> That makes it harder (would have taken longer than the 20 minutes I'd
> set aside). And it raises one issue: if this label is also a legal goto
> label, then:
>
> outerloop:
> for(;;) { while(1) {
> goto outerloop;
> break outerloop;
> }}
> // endofouterloop:
>
> the statements will jump to completely different points. The break
> actually goes to an implicit statement after the loop.
>
> At this point, it seems to me the following would actually be clearer:
>
> for(;;) { while(1) {
> goto endofouterloop;
> }}
> endofouterloop:
>
> as it pinpoints exactly where the code will end up next. With loads of
> nested }s floating around, many nothing to do with the loops, the end of
> the desired loop is not always easy to find.
Maybe, but for a "continue outerloop;" a label at the beginning would be
more appropriate, or even better, inside the loop.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2020-01-27 16:31 +1300 |
| Message-ID | <h973sbF25s3U13@mid.individual.net> |
| In reply to | #71604 |
On 27/01/2020 09:51, Bart wrote: > > I've implemented multi-level breaks (and a couple of other loop controls > you don't find in C and C++). > > If the inner loops are numbered from 1 (where the break statement is) to > N (outermost loop), then you write the equivalent of: > > break; // or break 1 > break 2 // next outer loop > break N; // break out of all loops C and C++ already have such an option; return. -- Ian.
[toc] | [prev] | [next] | [standalone]
Page 5 of 6 — ← Prev page 1 2 3 4 [5] 6 Next page →
Back to top | Article view | comp.lang.c++
csiph-web