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 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
| From | Siri Cruise <chine.bleu@yahoo.com> |
|---|---|
| Date | 2020-01-24 17:57 -0800 |
| Message-ID | <chine.bleu-322DC7.17573424012020@reader.eternal-september.org> |
| In reply to | #71560 |
In article <acfc347c-239e-4916-9ce8-8489d173018e@googlegroups.com>, Öö Tiib <ootiib@hot.ee> wrote: > > FWIW, I just grepped our C++ codebase (600 KLOC) for goto, it appears > > there is one goto per 8000 lines. This is a bit surprising, I did not > > expect so many gotos. > > Often it just is not worth to refactor code to get rid of gotos. > Real programmer can write fortran-program in any programming > language and gotos are smallest of issues with such. gotos are usually the easy and efficient way to write FSMs. -- :-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @ 'I desire mercy, not sacrifice.' /|\ The first law of discordiamism: The more energy This post / \ to make order is nore energy made into entropy. insults Islam. Mohammed
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-01-24 12:19 +0000 |
| Message-ID | <4hBWF.107660$LY2.60603@fx23.am4> |
| In reply to | #71537 |
On 24/01/2020 09:07, Bo Persson wrote: > On 2020-01-24 at 02:06, Bart wrote: >> On 22/01/2020 19:04, Christian Gollwitzer wrote: >>> What good reasons are left for a literal goto? I can see it in C for >>> error handling (because it lacks exceptions) - in C++ there is hardly >>> a good reason IMHO. >> Even with this, I think my incidence of using goto is once per 400 >> lines or so, so 'spaghetti code' is unlikely. >> > > I find that an extremely high use of goto. Would rather expect once in a > million lines, or so. IIRC 'goto' in the Linux kernel code was more like once in 200 lines. Some CPython sources I've just tested (all .c files, not .h, in the ./py directory combined into one 44Kloc file) use "goto " once per 230 lines. On Tiny C sources (again only .c files in main folder), it's once per 95 lines. On Lua sources however, it's once per 430 lines. (Neither Lua nor Python projects have 'goto' in the languages they implement.) Your once in a million lines sounds extreme. None of my projects are anywhere near that size. goto is inelegant but if it's the simplest way to code something, then I will use it. (On my own biggest project its once per 500 lines. This in a language that allows nested loop breaks.)
[toc] | [prev] | [next] | [standalone]
| From | Bo Persson <bo@bo-persson.se> |
|---|---|
| Date | 2020-01-24 14:19 +0100 |
| Message-ID | <h9096oFltbkU1@mid.individual.net> |
| In reply to | #71540 |
On 2020-01-24 at 13:19, Bart wrote:
> On 24/01/2020 09:07, Bo Persson wrote:
>> On 2020-01-24 at 02:06, Bart wrote:
>>> On 22/01/2020 19:04, Christian Gollwitzer wrote:
>
>>>> What good reasons are left for a literal goto? I can see it in C for
>>>> error handling (because it lacks exceptions) - in C++ there is
>>>> hardly a good reason IMHO.
>
>>> Even with this, I think my incidence of using goto is once per 400
>>> lines or so, so 'spaghetti code' is unlikely.
>>>
>>
>> I find that an extremely high use of goto. Would rather expect once in
>> a million lines, or so.
>
> IIRC 'goto' in the Linux kernel code was more like once in 200 lines.
>
> Some CPython sources I've just tested (all .c files, not .h, in the ./py
> directory combined into one 44Kloc file) use "goto " once per 230 lines.
>
> On Tiny C sources (again only .c files in main folder), it's once per 95
> lines.
>
> On Lua sources however, it's once per 430 lines. (Neither Lua nor Python
> projects have 'goto' in the languages they implement.)
>
> Your once in a million lines sounds extreme. None of my projects are
> anywhere near that size. goto is inelegant but if it's the simplest way
> to code something, then I will use it.
>
It wasn't so much about project sizes as about coding for years between
each time a goto has seemed even slightly useful.
Took a quick look at the Tiny C code (random choice tccasm.c) and found
some examples of goto between different cases of a switch statement,
goto from the if branch to the else part of an if-statement.
And this beauty:
redo:
if (tok == '#') {
/* horrible gas comment */
while (tok != TOK_LINEFEED)
next();
} else if (tok >= TOK_ASMDIR_FIRST && tok <= TOK_ASMDIR_LAST) {
asm_parse_directive(s1, global);
} else if (tok == TOK_PPNUM) {
const char *p;
int n;
p = tokc.str.data;
n = strtoul(p, (char **)&p, 10);
if (*p != '\0')
expect("':'");
/* new local label */
asm_new_label(s1, asm_get_local_label_name(s1, n), 1);
next();
skip(':');
goto redo;
} else if (tok >= TOK_IDENT) {
/* instruction or label */
opcode = tok;
next();
if (tok == ':') {
/* new label */
asm_new_label(s1, opcode, 0);
next();
goto redo;
} else if (tok == '=') {
set_symbol(s1, opcode);
goto redo;
} else {
asm_opcode(s1, opcode);
}
}
where you have 3 goto's back to redo, instead of a for(;;) and breaks
for the cases when you don't want to redo anything. Not an example to
follow!
Bo Persson
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-01-24 14:11 +0000 |
| Message-ID | <OWCWF.89705$OZ3.35385@fx28.am4> |
| In reply to | #71542 |
On 24/01/2020 13:19, Bo Persson wrote:
> On 2020-01-24 at 13:19, Bart wrote:
>> On 24/01/2020 09:07, Bo Persson wrote:
>>> On 2020-01-24 at 02:06, Bart wrote:
>>>> On 22/01/2020 19:04, Christian Gollwitzer wrote:
>>
>>>>> What good reasons are left for a literal goto? I can see it in C
>>>>> for error handling (because it lacks exceptions) - in C++ there is
>>>>> hardly a good reason IMHO.
>>
>>>> Even with this, I think my incidence of using goto is once per 400
>>>> lines or so, so 'spaghetti code' is unlikely.
>>>>
>>>
>>> I find that an extremely high use of goto. Would rather expect once
>>> in a million lines, or so.
>>
>> IIRC 'goto' in the Linux kernel code was more like once in 200 lines.
>>
>> Some CPython sources I've just tested (all .c files, not .h, in the
>> ./py directory combined into one 44Kloc file) use "goto " once per 230
>> lines.
>>
>> On Tiny C sources (again only .c files in main folder), it's once per
>> 95 lines.
>>
>> On Lua sources however, it's once per 430 lines. (Neither Lua nor
>> Python projects have 'goto' in the languages they implement.)
>>
>> Your once in a million lines sounds extreme. None of my projects are
>> anywhere near that size. goto is inelegant but if it's the simplest
>> way to code something, then I will use it.
>>
>
> It wasn't so much about project sizes as about coding for years between
> each time a goto has seemed even slightly useful.
>
>
> Took a quick look at the Tiny C code (random choice tccasm.c) and found
> some examples of goto between different cases of a switch statement,
> goto from the if branch to the else part of an if-statement.
>
> And this beauty:
>
> redo:
> if (tok == '#') {
> /* horrible gas comment */
> while (tok != TOK_LINEFEED)
> next();
> } else if (tok >= TOK_ASMDIR_FIRST && tok <= TOK_ASMDIR_LAST) {
> asm_parse_directive(s1, global);
> } else if (tok == TOK_PPNUM) {
> const char *p;
> int n;
> p = tokc.str.data;
> n = strtoul(p, (char **)&p, 10);
> if (*p != '\0')
> expect("':'");
> /* new local label */
> asm_new_label(s1, asm_get_local_label_name(s1, n), 1);
> next();
> skip(':');
> goto redo;
> } else if (tok >= TOK_IDENT) {
> /* instruction or label */
> opcode = tok;
> next();
> if (tok == ':') {
> /* new label */
> asm_new_label(s1, opcode, 0);
> next();
> goto redo;
> } else if (tok == '=') {
> set_symbol(s1, opcode);
> goto redo;
> } else {
> asm_opcode(s1, opcode);
> }
> }
>
> where you have 3 goto's back to redo, instead of a for(;;) and breaks
> for the cases when you don't want to redo anything. Not an example to
> follow!
That does look poor. But bear in mind, this block is already part of an
outer for(;;) loop.
With nested loops, and with a lot of the code using switch rather than
if-else, 'break' is under some pressure: you can't use it to jump out of
a loop if inside a switch, and you can't use it to jump out of an outer
loop whether in a switch or not.
(And conversely, if you have 'break' inside an if-else chain inside a
loop, you can't convert the if-else chain into a switch, without finding
alternatives to those breaks, if you've even spotted the issue.)
I think this example belongs to my first use-case: while developing, you
temporarily put in thesedirty fixes to get things to work, with a mind
to reviewing later when you have the full picture of the final working
code. This apparently never got done.
But remember, Tiny C is probably the world's fastest C compiler; you
have to cut it some slack!
(Also, I believe Tiny C started off as an IOCCC entry.)
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2020-01-24 17:26 +0000 |
| Message-ID | <slrnr2ma6t.km3.grahn+nntp@frailea.sa.invalid> |
| In reply to | #71540 |
On Fri, 2020-01-24, Bart wrote: > On 24/01/2020 09:07, Bo Persson wrote: >> On 2020-01-24 at 02:06, Bart wrote: >>> On 22/01/2020 19:04, Christian Gollwitzer wrote: > >>>> What good reasons are left for a literal goto? I can see it in C for >>>> error handling (because it lacks exceptions) - in C++ there is hardly >>>> a good reason IMHO. > >>> Even with this, I think my incidence of using goto is once per 400 >>> lines or so, so 'spaghetti code' is unlikely. >>> >> >> I find that an extremely high use of goto. Would rather expect once in a >> million lines, or so. > > IIRC 'goto' in the Linux kernel code was more like once in 200 lines. > > Some CPython sources I've just tested (all .c files, not .h, in the ./py > directory combined into one 44Kloc file) use "goto " once per 230 lines. > > On Tiny C sources (again only .c files in main folder), it's once per 95 > lines. > > On Lua sources however, it's once per 430 lines. (Neither Lua nor Python > projects have 'goto' in the languages they implement.) Those are all C examples. The context here was C++. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-01-24 17:35 +0000 |
| Message-ID | <ZVFWF.603350$GFe.375230@fx12.am4> |
| In reply to | #71546 |
On 24/01/2020 17:26, Jorgen Grahn wrote: > On Fri, 2020-01-24, Bart wrote: >> On 24/01/2020 09:07, Bo Persson wrote: >>> On 2020-01-24 at 02:06, Bart wrote: >>>> On 22/01/2020 19:04, Christian Gollwitzer wrote: >> >>>>> What good reasons are left for a literal goto? I can see it in C for >>>>> error handling (because it lacks exceptions) - in C++ there is hardly >>>>> a good reason IMHO. >> >>>> Even with this, I think my incidence of using goto is once per 400 >>>> lines or so, so 'spaghetti code' is unlikely. >>>> >>> >>> I find that an extremely high use of goto. Would rather expect once in a >>> million lines, or so. >> >> IIRC 'goto' in the Linux kernel code was more like once in 200 lines. >> >> Some CPython sources I've just tested (all .c files, not .h, in the ./py >> directory combined into one 44Kloc file) use "goto " once per 230 lines. >> >> On Tiny C sources (again only .c files in main folder), it's once per 95 >> lines. >> >> On Lua sources however, it's once per 430 lines. (Neither Lua nor Python >> projects have 'goto' in the languages they implement.) > > Those are all C examples. The context here was C++. I can't see much in C++ that would eliminate the use-cases for goto in C. C++ has exceptions that work across functions, but C doesn't even use goto for those
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2020-01-24 22:27 +0200 |
| Message-ID | <r0fk0a$ms0$1@dont-email.me> |
| In reply to | #71548 |
On 24.01.2020 19:35, Bart wrote: > On 24/01/2020 17:26, Jorgen Grahn wrote: >> >> Those are all C examples. The context here was C++. > > I can't see much in C++ that would eliminate the use-cases for goto in C. > > C++ has exceptions that work across functions, but C doesn't even use > goto for those How come? How one can sanely cope with error checking in C without goto, if there is even a single resource to be released before error return? In a single .c file I have 57 gotos, that's about the same amount as for the whole C++ codebase of over half a million lines.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2020-01-24 23:21 -0500 |
| Message-ID | <r0gfnh$3tt$1@dont-email.me> |
| In reply to | #71550 |
On 1/24/20 3:27 PM, Paavo Helde wrote: ... > How come? How one can sanely cope with error checking in C without goto, > if there is even a single resource to be released before error return? You might consider my approach insane. Instead of using goto to make sure the resource is released, I release each resource at the end of the block that is entered if and only if that resource was successfully allocated, and I make sure never to leave that block by any means other than passing through the release statement. And I only use C's other flow control statements, not "goto", to make that happen. And that is true separately for each such resource.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2020-01-25 11:06 +1300 |
| Message-ID | <h9183lF25s3U5@mid.individual.net> |
| In reply to | #71548 |
On 25/01/2020 06:35, Bart wrote: > On 24/01/2020 17:26, Jorgen Grahn wrote: >> On Fri, 2020-01-24, Bart wrote: >>> On 24/01/2020 09:07, Bo Persson wrote: >>>> On 2020-01-24 at 02:06, Bart wrote: >>>>> On 22/01/2020 19:04, Christian Gollwitzer wrote: >>> >>>>>> What good reasons are left for a literal goto? I can see it in C for >>>>>> error handling (because it lacks exceptions) - in C++ there is hardly >>>>>> a good reason IMHO. >>> >>>>> Even with this, I think my incidence of using goto is once per 400 >>>>> lines or so, so 'spaghetti code' is unlikely. >>>>> >>>> >>>> I find that an extremely high use of goto. Would rather expect once in a >>>> million lines, or so. >>> >>> IIRC 'goto' in the Linux kernel code was more like once in 200 lines. >>> >>> Some CPython sources I've just tested (all .c files, not .h, in the ./py >>> directory combined into one 44Kloc file) use "goto " once per 230 lines. >>> >>> On Tiny C sources (again only .c files in main folder), it's once per 95 >>> lines. >>> >>> On Lua sources however, it's once per 430 lines. (Neither Lua nor Python >>> projects have 'goto' in the languages they implement.) >> >> Those are all C examples. The context here was C++. > > I can't see much in C++ that would eliminate the use-cases for goto in C. > > C++ has exceptions that work across functions, but C doesn't even use > goto for those Our code base (about 2500 C++ source files) has few exceptions and not one goto. There really is no need for it. -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2020-01-24 22:12 +0000 |
| Message-ID | <slrnr2mqv7.km3.grahn+nntp@frailea.sa.invalid> |
| In reply to | #71548 |
On Fri, 2020-01-24, Bart wrote: > On 24/01/2020 17:26, Jorgen Grahn wrote: >> On Fri, 2020-01-24, Bart wrote: >>> On 24/01/2020 09:07, Bo Persson wrote: >>>> On 2020-01-24 at 02:06, Bart wrote: >>>>> On 22/01/2020 19:04, Christian Gollwitzer wrote: >>> >>>>>> What good reasons are left for a literal goto? I can see it in C for >>>>>> error handling (because it lacks exceptions) - in C++ there is hardly >>>>>> a good reason IMHO. >>> >>>>> Even with this, I think my incidence of using goto is once per 400 >>>>> lines or so, so 'spaghetti code' is unlikely. >>>>> >>>> >>>> I find that an extremely high use of goto. Would rather expect once in a >>>> million lines, or so. >>> >>> IIRC 'goto' in the Linux kernel code was more like once in 200 lines. >>> >>> Some CPython sources I've just tested (all .c files, not .h, in the ./py >>> directory combined into one 44Kloc file) use "goto " once per 230 lines. >>> >>> On Tiny C sources (again only .c files in main folder), it's once per 95 >>> lines. >>> >>> On Lua sources however, it's once per 430 lines. (Neither Lua nor Python >>> projects have 'goto' in the languages they implement.) >> >> Those are all C examples. The context here was C++. > > I can't see much in C++ that would eliminate the use-cases for goto in C. Of course not -- how could a feature in language X eliminate the need for another feature in language Y? /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-24 23:24 -0500 |
| Message-ID | <r0gfuo$5aa$1@dont-email.me> |
| In reply to | #71554 |
On 1/24/20 5:12 PM, Jorgen Grahn wrote: > On Fri, 2020-01-24, Bart wrote: ... >> I can't see much in C++ that would eliminate the use-cases for goto in C. > > Of course not -- how could a feature in language X eliminate the need > for another feature in language Y? I suspect he meant "I can't see much in C++ that would eliminate, in C++, the use-cases that, in C, justify the use of goto." The only reasonably plausible justifications I've seen for using "goto" are for error handling, and the kind of error handling that justifies using "goto" is handled somewhat more easily in C++ by using exceptions, but I'm not at all surprised if Bart can't see that.
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2020-01-25 09:04 +0000 |
| Message-ID | <slrnr2o140.km3.grahn+nntp@frailea.sa.invalid> |
| In reply to | #71563 |
On Sat, 2020-01-25, James Kuyper wrote: > On 1/24/20 5:12 PM, Jorgen Grahn wrote: >> On Fri, 2020-01-24, Bart wrote: > ... >>> I can't see much in C++ that would eliminate the use-cases for goto in C. >> >> Of course not -- how could a feature in language X eliminate the need >> for another feature in language Y? > > I suspect he meant "I can't see much in C++ that would eliminate, in > C++, the use-cases that, in C, justify the use of goto." Seems right, based on his later posting: "as I said earlier, it's not clear how much C++ helps avoiding gotos compared with C". I had a hard time understanding what this subthread was all about, so I didn't want to take a guess on what he meant. > The only reasonably plausible justifications I've seen for using "goto" > are for error handling, and the kind of error handling that justifies > using "goto" is handled somewhat more easily in C++ by using exceptions, That too, but mostly by RAII, as Ian pointed out. > but I'm not at all surprised if Bart can't see that. I'm mildly surprised that he cares. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2020-01-25 04:15 -0800 |
| Message-ID | <c06a4aa7-f087-49c3-b4b4-ae8b56f401e3@googlegroups.com> |
| In reply to | #71563 |
On Saturday, 25 January 2020 06:25:04 UTC+2, James Kuyper wrote: > On 1/24/20 5:12 PM, Jorgen Grahn wrote: > > On Fri, 2020-01-24, Bart wrote: > ... > >> I can't see much in C++ that would eliminate the use-cases for goto in C. > > > > Of course not -- how could a feature in language X eliminate the need > > for another feature in language Y? > > I suspect he meant "I can't see much in C++ that would eliminate, in > C++, the use-cases that, in C, justify the use of goto." > > The only reasonably plausible justifications I've seen for using "goto" > are for error handling, and the kind of error handling that justifies > using "goto" is handled somewhat more easily in C++ by using exceptions, > but I'm not at all surprised if Bart can't see that. It is actually possible on lot of cases with gotos to optimize out duplicate condition checks, switch cases, calls through (possibly member) function pointers or virtual function calls. It indeed often also means that the result is slightly harder to follow, to extend and to test. Any such micro-performance optimizations should be avoided unless profiler shows that there is something to gain. Profiler however typically shows that less than 5% of code base contributes anything to time consumption. However when the goto is already written, the tests are already present and there are no reasons to expect that it needs to be extended soon then I do not understand why to refactor it? It feels to be waste of effort. Why to risk breaking working code? Why to gain reduced efficiency? The gotos are very local (unlike for example macros or exceptions) so the impact is minimal.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-01-25 19:55 +0100 |
| Message-ID | <r0i2ul$kig$1@dont-email.me> |
| In reply to | #71563 |
On 25/01/2020 05:24, James Kuyper wrote: > On 1/24/20 5:12 PM, Jorgen Grahn wrote: >> On Fri, 2020-01-24, Bart wrote: > ... >>> I can't see much in C++ that would eliminate the use-cases for goto in C. >> >> Of course not -- how could a feature in language X eliminate the need >> for another feature in language Y? > > I suspect he meant "I can't see much in C++ that would eliminate, in > C++, the use-cases that, in C, justify the use of goto." > > The only reasonably plausible justifications I've seen for using "goto" > are for error handling, and the kind of error handling that justifies > using "goto" is handled somewhat more easily in C++ by using exceptions, > but I'm not at all surprised if Bart can't see that. > "goto" is not used in C for error handling as such - it is used to handle deallocation of resources in the face of abnormal program flow (such as in the case of an error, but possibly from other situations). And the way this is handled in C++ is not exceptions - it is RAII. Exceptions are used to be able to pass control to a separate block with little source code needed in between - thus letting you have error handling without having to write the error handling manually in the code that could have an error. So in C, people (not everyone, but some people write) : Get resource 1 if (failed) goto exit if (leave early) goto release1 Get resource 2 if (failed) goto release1 if (leave early) goto release2 Use resource 1 and resource 2 release2: Release resource 2 release1: Release resource 1 exit: return In C++, you can write: auto r1 = Get resource 1 if (failed or leave early) return auto r2 = Get resource 2 if (failed or leave early) return Use resource 1 and resource 2 return You can use early return, break, exceptions, goto, or whatever you want to leave the code block. It is the /RAII/ that avoids the "goto" and labels collections needed to handle leak-free early exit, not exceptions.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-01-25 00:05 +0100 |
| Message-ID | <r0ft7j$gun$1@dont-email.me> |
| In reply to | #71540 |
On 24/01/2020 13:19, Bart wrote: > On 24/01/2020 09:07, Bo Persson wrote: >> On 2020-01-24 at 02:06, Bart wrote: >>> On 22/01/2020 19:04, Christian Gollwitzer wrote: > >>>> What good reasons are left for a literal goto? I can see it in C for >>>> error handling (because it lacks exceptions) - in C++ there is >>>> hardly a good reason IMHO. > >>> Even with this, I think my incidence of using goto is once per 400 >>> lines or so, so 'spaghetti code' is unlikely. >>> >> >> I find that an extremely high use of goto. Would rather expect once in >> a million lines, or so. > > IIRC 'goto' in the Linux kernel code was more like once in 200 lines. > > Some CPython sources I've just tested (all .c files, not .h, in the ./py > directory combined into one 44Kloc file) use "goto " once per 230 lines. > > On Tiny C sources (again only .c files in main folder), it's once per 95 > lines. > > On Lua sources however, it's once per 430 lines. (Neither Lua nor Python > projects have 'goto' in the languages they implement.) > > Your once in a million lines sounds extreme. None of my projects are > anywhere near that size. goto is inelegant but if it's the simplest way > to code something, then I will use it. I can only ever remember /once/ using "goto" in C code (and that was only for a while - it got removed after a refactoring). I don't know how many lines I have written over the years, in all my work - I don't think it would be a million lines, but it is a great deal. Different people code in different ways and have different requirements. I suspect you'll find "goto" occurring most in either badly written and badly structured code (we all know this kind of code exists, but lets ignore it for now), for generated code (again, we'll ignore that), or code where there is a strong emphasis on good performance even in the face of poor compilers (or no optimisation enabled) and older C standards. For this kind of thing, there are going to be more situations where "goto" (or other unstructured code practices, like non-trivial switch case fall-throughs) can be a definite help in getting efficient results. When you have better tools (or don't care about performance), there are many more options available. You can re-factor code into smaller functions, and leave nested loops with a "return" - in the knowledge that the compiler will inline these single-use static functions and give you just as efficient results. You can add extra booleans for flags and put them in the conditionals for the loops - knowing the compiler will turn them into goto's. You can duplicate code (not often a great idea, but sometimes the neatest and clearest solution), knowing the compiler will merge duplicate code sections without manual goto's or switch case fall-throughs. I am all in favour of using a coding technique if I think it is the simplest, clearest, and most maintainable option. The reason I don't use goto's myself is that I have never found it to be the best choice for my code - not because of a particular allergy against it. > > (On my own biggest project its once per 500 lines. This in a language > that allows nested loop breaks.)
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-01-25 01:19 +0000 |
| Message-ID | <lIMWF.216643$oQ3.163953@fx29.am4> |
| In reply to | #71555 |
On 24/01/2020 23:05, David Brown wrote: > On 24/01/2020 13:19, Bart wrote: >> Your once in a million lines sounds extreme. None of my projects are >> anywhere near that size. goto is inelegant but if it's the simplest >> way to code something, then I will use it. > > I can only ever remember /once/ using "goto" in C code (and that was > only for a while - it got removed after a refactoring). I don't know > how many lines I have written over the years, in all my work - I don't > think it would be a million lines, but it is a great deal. Different > people code in different ways and have different requirements. > > I suspect you'll find "goto" occurring most in either badly written and > badly structured code (we all know this kind of code exists, but lets > ignore it for now), for generated code (again, we'll ignore that), or > code where there is a strong emphasis on good performance even in the > face of poor compilers (or no optimisation enabled) and older C > standards. For this kind of thing, there are going to be more > situations where "goto" (or other unstructured code practices, like > non-trivial switch case fall-throughs) can be a definite help in getting > efficient results. > > When you have better tools (or don't care about performance), there are > many more options available. You can re-factor code into smaller > functions, and leave nested loops with a "return" - in the knowledge > that the compiler will inline these single-use static functions and give > you just as efficient results. You can add extra booleans for flags and > put them in the conditionals for the loops - knowing the compiler will > turn them into goto's. You can duplicate code (not often a great idea, > but sometimes the neatest and clearest solution), knowing the compiler > will merge duplicate code sections without manual goto's or switch case > fall-throughs. > > I am all in favour of using a coding technique if I think it is the > simplest, clearest, and most maintainable option. The reason I don't > use goto's myself is that I have never found it to be the best choice > for my code - not because of a particular allergy against it. Well, I've never seen any actual code of yours, only fragments that you might post, so I don't know what the cost might be in terms of readability, or loss of localisation (eg. when you have to invent dummy functions etc to avoid use of goto) or things like that. (Or how much longer it takes to write such code.) 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. Even within only the header files, there are 500 gotos in some 6M lines of headers, or once every 12,000 lines; still far more that you write in actual C code. Or C++; as I said earlier, it's not clear how much C++ helps avoiding gotos compared with C. C++-style exceptions would be handled by longjmp in C? Then that wouldn't count as a goto. On the subject of never using a common feature of a language (or development system), then I've never written a makefile. And in the last 1.7Kloc pure C module I wrote, I didn't use a single macro. I tend to use gotos to share the same fragment of code within a function. I once came up with a new feature to make that possible without gotos, like in-place, lightweight, not-parameterised local functions, but their use resembled Basic's GOSUB; I decided I might as well just use goto!
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2020-01-25 19:50 +1300 |
| Message-ID | <h926ovF25s3U6@mid.individual.net> |
| In reply to | #71559 |
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. > Or C++; as I said earlier, it's not clear how much C++ helps avoiding > gotos compared with C. C++-style exceptions would be handled by longjmp > in C? Then that wouldn't count as a goto. RAII takes care of one of the most common use of goto in C which is freeing allocated resources on error. It also allows early returns which eliminates another significant use of goto in C. -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-01-25 11:57 +0000 |
| Message-ID | <K2WWF.227060$vS6.23920@fx24.am4> |
| In reply to | #71565 |
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..."
[toc] | [prev] | [next] | [standalone]
| From | Chris Vine <chris@cvine--nospam--.freeserve.co.uk> |
|---|---|
| Date | 2020-01-25 13:42 +0000 |
| Message-ID | <20200125134202.8939b7b4f1db1e1f59c1411d@cvine--nospam--.freeserve.co.uk> |
| In reply to | #71567 |
On Sat, 25 Jan 2020 11:57:24 +0000 Bart <bc@freeuk.com> 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..." And you said: "Or C++; as I said earlier, it's not clear how much C++ helps avoiding gotos compared with C. C++-style exceptions would be handled by longjmp in C? Then that wouldn't count as a goto." The point you were missing, and still seem to be missing, is that C++'s RAII (which caters for early returns) dispenses with the need to use goto's and labels for implementing what amounts to finally clauses in C, which is probably its most common usage in the linux kernel.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-01-25 14:58 +0000 |
| Message-ID | <zIYWF.84332$iK5.17923@fx34.am4> |
| In reply to | #71569 |
On 25/01/2020 13:42, Chris Vine wrote:
> On Sat, 25 Jan 2020 11:57:24 +0000
> Bart <bc@freeuk.com> wrote:
>> David Brown said:
>>
>> "I can only ever remember /once/ using "goto" in C code..."
>
> And you said:
>
> "Or C++; as I said earlier, it's not clear how much C++ helps avoiding
> gotos compared with C. C++-style exceptions would be handled by longjmp
> in C? Then that wouldn't count as a goto."
>
> The point you were missing, and still seem to be missing, is that C++'s
> RAII (which caters for early returns) dispenses with the need to use
> goto's and labels for implementing what amounts to finally clauses in C,
> which is probably its most common usage in the linux kernel.
>
I chose one random file, workqueue.c, and scanned a few gotos. They
seemed to be backward jumps. For example:
reflush:
flush_workqueue(wq);
mutex_lock(&wq->mutex);
for_each_pwq(pwq, wq) {
bool drained;
spin_lock_irq(&pwq->pool->lock);
drained = !pwq->nr_active && list_empty(&pwq->delayed_works);
spin_unlock_irq(&pwq->pool->lock);
if (drained)
continue;
if (++flush_cnt == 10 ||
(flush_cnt % 100 == 0 && flush_cnt <= 1000))
pr_warn("workqueue %s: drain_workqueue() isn't complete after %u
tries\n",
wq->name, flush_cnt);
mutex_unlock(&wq->mutex);
goto reflush;
}
This looks like it really needs two nested loops rather than one, but
probably requires nested loop controls, so means extra flags.
How would C++ help here, to avoid either that extra logic, or the use of
that goto? Here's the current outline (for_each_pwq is a macro expanding
to a regular for-header):
L:
A;
for (...) {
B;
if (C) continue;
D;
goto L;
}
This can be done without gotos and without additional logic in my own
language, as it supports nested loop controls:
do
A
for ... do
B
if C then next fi # next=continue, sort of
D
redo all # restart outer loop body
end
exit # exit=break
end
(Another way is for the outer loop to be 'to 1 do', execute once, to
avoid that exit.)
So I genuinely have features to help cut back on use of goto, yet I
still use goto because, as I said, I mainly use it for share code
fragments within a function.
(I then looked at one more example, which was this (umh.c), here only
outlined:
...
if (A) {
B;
if (C) {
D;
goto L;
}
}
E;
L:
G;
} // end of function
Any ideas? This one seems more about code-sharing. I'm still interested
in any C++ magic to help out. Rewriting 25MLoC is not a helpful
suggestion...)
[toc] | [prev] | [next] | [standalone]
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
Back to top | Article view | comp.lang.c++
csiph-web