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 | 13 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 6 of 6 — ← Prev page 1 2 3 4 5 [6]
| From | Manfred <noname@add.invalid> |
|---|---|
| Date | 2020-01-26 18:50 +0100 |
| Message-ID | <r0kjgr$1h78$1@gioia.aioe.org> |
| In reply to | #71592 |
On 1/26/2020 2:58 PM, David Brown wrote: > On 26/01/2020 13:44, Bart wrote: >> >> No, the use-cases for goto are always there: > > No, they are not. I wouldn't be that hard. > >> 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. This is an interesting point. The fact is that what is considered to be good code structure is subjective, because it has to do with how it fits the programmer mindset (either the writer's or reader's). And (fortunately) that is not fixed for everyone (it is, to some extent, in the eye of the beholder). I personally never had the need for goto, because my way of structuring code does not fit well with it (this is probably similar to your attitude). However, I am willing to consider that this may be due to my background with coding (I started with Fortan, then C and shortly after that C++), and give the benefit of the doubt to someone who may have had a different path - specifically if having a considerable background or habit with ASM (I have no idea if this is Bart's case, but it may fit kernel programmers). In other words, in ASM programming goto (its equivalents) is ubiquitous, thus, to someone used to that way of coding, I would not be surprised that goto is clearer and more readable than structured loops more often than I would think. From that perspective, goto in C++ coding is considerably less useful than in C. > > 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. This is true, but in case of kernel code I understand why they didn't want to put those "extra tests, duplicated calculations, local flag variables, etc." in the source in the first place. <snip> > >> (No macros either in that project.) > > Only you consider that a good thing. > (I think in comp.lang.c++ there are more people who do not consider macros a good thing)
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2020-01-26 18:57 +0000 |
| Message-ID | <slrnr2ro90.km3.grahn+nntp@frailea.sa.invalid> |
| In reply to | #71597 |
On Sun, 2020-01-26, Manfred wrote: > On 1/26/2020 2:58 PM, David Brown wrote: ... >> 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. > > This is an interesting point. The fact is that what is considered to be > good code structure is subjective, because it has to do with how it fits > the programmer mindset (either the writer's or reader's). And > (fortunately) that is not fixed for everyone (it is, to some extent, in > the eye of the beholder). Less so than many other things (like naming and high-level design), I think. There's Dijkstra, there's Structured programming, and a general agreement that complex loops, complex loop conditions and vague invariants are worse than simpler ones. (But people surely disagree about how much effort should be spent making the structure good/better.) /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-01-26 20:46 +0100 |
| Message-ID | <r0kqbd$h7$1@dont-email.me> |
| In reply to | #71597 |
On 26/01/2020 18:50, Manfred wrote: > On 1/26/2020 2:58 PM, David Brown wrote: >> On 26/01/2020 13:44, Bart wrote: >>> >>> No, the use-cases for goto are always there: >> >> No, they are not. > > I wouldn't be that hard. I don't think these "use-cases for goto" exist (outside of generated code) - not in the sense of programming tasks for which "goto" is the best answer, or the only natural choice. But other people have different balances of how they like to code, and what they consider "best". And of course there can be differences for different types of programming tasks. (For one thing, keeping a consistent style with existing code in a project is often very important - even if it is not a great style to begin with.) However, what we can definitely say is that for myself and for several other people in this thread, each with decades of experience at C and/or C++ coding, these "use-cases for goto" are not there in the tasks we face. > >> >>> 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. > > This is an interesting point. The fact is that what is considered to be > good code structure is subjective, because it has to do with how it fits > the programmer mindset (either the writer's or reader's). And > (fortunately) that is not fixed for everyone (it is, to some extent, in > the eye of the beholder). Agreed. > I personally never had the need for goto, because my way of structuring > code does not fit well with it (this is probably similar to your attitude). > However, I am willing to consider that this may be due to my background > with coding (I started with Fortan, then C and shortly after that C++), > and give the benefit of the doubt to someone who may have had a > different path - specifically if having a considerable background or > habit with ASM (I have no idea if this is Bart's case, but it may fit > kernel programmers). > In other words, in ASM programming goto (its equivalents) is ubiquitous, > thus, to someone used to that way of coding, I would not be surprised > that goto is clearer and more readable than structured loops more often > than I would think. I have a strong background in assembly too. And BASIC before that. (And a dozen or more languages after that, to varying degrees.) But I agree that background has an influence here. In particular, some people seem to consider software development as something you learn once and do in the same way ever after - even if the language changes. They might be using C++ on the latest MSVC or gcc compiler, but they are using K&R 1 as their bible and declare all their variables at the start of their functions because that's what they learned for Pascal at school in 1980. I am not suggesting you have to be that extreme to use gotos in your code (nor am I accusing any particular poster here of being such a programmer, before anyone takes offence), but I think there is a strong element of old-fashioned style in goto-rich code. > > From that perspective, goto in C++ coding is considerably less useful > than in C. > >> >> 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. > > This is true, but in case of kernel code I understand why they didn't > want to put those "extra tests, duplicated calculations, local flag > variables, etc." in the source in the first place. > Linux is old - and its origins go back to a time when you needed "manual optimisation" to get efficient results. You don't need them now - the kernel won't compile with a compiler that can't do reasonable optimisation. But there is good sense in keeping a consistent style with existing code, and there is good sense in not changing existing code unnecessarily, especially in a project with such a wide spread of developers involved. > <snip> >> >>> (No macros either in that project.) >> >> Only you consider that a good thing. >> > > (I think in comp.lang.c++ there are more people who do not consider > macros a good thing) Abuse of macros is a bad thing - I hope all will agree on that. Use of macros when there are better alternatives is a bad thing - again, I hope that will have full agreement. And C++ provides more alternatives than C does for many typical use-cases of macros. Some of the disadvantages of macros may be even more problematic in C++, such as their unscoped nature (since C++ has more scoping levels than C). All this changes the balance of when it is a good thing (making code clearer, simpler and easier to maintain) or a bad thing to use a macro in C or C++. So there are fewer circumstances when a macro is a good solution in C++ than there are in C. But you can't generalise that macros are good or bad - it is only usage (including definitions) of particular macros that are good or bad.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2020-01-26 13:14 -0600 |
| Message-ID | <mjnr2f9d1jkh6cb4a5fv2qnrj9vvi0jrbt@4ax.com> |
| In reply to | #71592 |
On Sun, 26 Jan 2020 14:58:45 +0100, David Brown <david.brown@hesbynett.no> wrote: >On 26/01/2020 13:44, Bart wrote: >> 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. I don't think efficiency is a main concern here, or even an important one. Rather some uses of goto are, at least IMO, clearer than many of the alternatives. The error handling and nested-loop escape being two common ones. C++/RAII mostly removes one of those. Certainly everything can be written without gotos, I just don't think that's always the clearest way to write the code. "Clarity" being a somewhat subjective determination, of course. A bit of code in an unfamiliar idiom, even if simpler, can be less "clear". Still, gotos should be used quite sparingly. And uses should avoid the "spaghetti" code of the distant past. On the other hand, this is a bit of a tempest in a teapot. When Dijkstra wrote "Goto considered harmful", his context was unrestricted branching across large monolithic programs (sometimes 10's of KLOCs). The problems that introduces are just not possible if you have reasonably sized routines. I'm not suggesting that unrestricted branching across a 50 line routine is a good idea, but he'd never have written that paper to deal with those issues. You just cannot have the morass you get from a bunch of labels in a chunk of code referenced by dozens of gotos, many from multiple thousands of lines away. I just think people have gone a bit overboard with the idea, so that it's ended up as "if there's any way to avoid a goto, do so" (which we know is actually always possible*), rather than focusing on clarity. *That's even been shown to be generally possible to do mechanically. For a while there was a market in restructuring tools (mostly for Cobol), that would turn any unstructured (Cobol) program into one with none of those nasty gotos. A complete horror was a common result, where the program got turned into a mess of state machines and state variables implemented as endless IF blocks, and making the old version of the program a relative paragon of clarity. But there were no gotos.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-01-26 22:15 +0100 |
| Message-ID | <r0kvgu$jg$1@dont-email.me> |
| In reply to | #71600 |
On 26/01/2020 20:14, Robert Wessel wrote: > > I just think people have gone a bit overboard with the idea, so that > it's ended up as "if there's any way to avoid a goto, do so" (which we > know is actually always possible*), rather than focusing on clarity. > Speaking only for myself, my focus /is/ on clarity. My focus is not "avoiding goto", certainly not on "removing goto", and not based on the old "Goto considered harmful" paper (no matter how much I respect the author). As you say, the context of that paper is different from the situation now, and I think we can all agree that spaghetti programming is a bad idea. And I agree that occasionally a goto may be a clear way to write code - it simply hasn't been a clear way to write any code that /I/ have had to write. I do think, however, that if you have a function for which a goto would seem the clearest solution, then it is likely to be an overly complex function. Functions with too many paths, branches, loops, etc., are often hard to analyse (mentally, formally or with analysis tools) to be sure all the paths and loops work as expected. A "goto" should always be treated with suspicion - either it is a poor solution to the problem, or perhaps you need to change the problem. I am sure there are some types of coding situations where goto is considered a reasonable choice - I just don't meet these situations.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2020-01-27 21:06 -0600 |
| Message-ID | <h78v2fpa5rqmo5uq0ggpe9v0hrf3scenhr@4ax.com> |
| In reply to | #71605 |
On Sun, 26 Jan 2020 22:15:06 +0100, David Brown <david.brown@hesbynett.no> wrote: >On 26/01/2020 20:14, Robert Wessel wrote: > >> >> I just think people have gone a bit overboard with the idea, so that >> it's ended up as "if there's any way to avoid a goto, do so" (which we >> know is actually always possible*), rather than focusing on clarity. >> > >Speaking only for myself, my focus /is/ on clarity. My focus is not >"avoiding goto", certainly not on "removing goto", and not based on the >old "Goto considered harmful" paper (no matter how much I respect the >author). As you say, the context of that paper is different from the >situation now, and I think we can all agree that spaghetti programming >is a bad idea. Let me emphasize, I didn't intend to accuse you of that sort of closed mindedness, and if it came across that way, I apologize. There are many people, though, who have heard a rule, and gosh darn it, they're going to apply it, no matter what. Unfortunately it seems to be prevalent with people who are in charge of writing and enforcing coding standards. That being said, I don't think we're really disagreeing on all that much. >And I agree that occasionally a goto may be a clear way to write code - >it simply hasn't been a clear way to write any code that /I/ have had to >write. > >I do think, however, that if you have a function for which a goto would >seem the clearest solution, then it is likely to be an overly complex >function. Functions with too many paths, branches, loops, etc., are >often hard to analyse (mentally, formally or with analysis tools) to be >sure all the paths and loops work as expected. A "goto" should always >be treated with suspicion - either it is a poor solution to the problem, >or perhaps you need to change the problem. > >I am sure there are some types of coding situations where goto is >considered a reasonable choice - I just don't meet these situations. Different people will disagree about issues of style and clarity. That's inevitable. Take the endless brace-style discussions (please!). But if I come work on one of your projects, I'll follow your project's standards. And perhaps I might struggle a bit in some of the (occasional) cases where I might consider a goto, or if your standards for routine length might be a bit shorter than ours, or whatever, simply because that somewhat changes the idioms I'm used to using every day. And if you come work on one of mine, I'll trust you not to run off and refactor everything that doesn't meet your preferences. And we can both (good naturedly) grumble about the wrong-headedness of the other approach at the water cooler.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-01-28 13:08 +0100 |
| Message-ID | <r0p88b$jd9$1@dont-email.me> |
| In reply to | #71633 |
On 28/01/2020 04:06, Robert Wessel wrote:
> On Sun, 26 Jan 2020 22:15:06 +0100, David Brown
> <david.brown@hesbynett.no> wrote:
>
>> On 26/01/2020 20:14, Robert Wessel wrote:
>>
>>>
>>> I just think people have gone a bit overboard with the idea, so that
>>> it's ended up as "if there's any way to avoid a goto, do so" (which we
>>> know is actually always possible*), rather than focusing on clarity.
>>>
>>
>> Speaking only for myself, my focus /is/ on clarity. My focus is not
>> "avoiding goto", certainly not on "removing goto", and not based on the
>> old "Goto considered harmful" paper (no matter how much I respect the
>> author). As you say, the context of that paper is different from the
>> situation now, and I think we can all agree that spaghetti programming
>> is a bad idea.
>
>
> Let me emphasize, I didn't intend to accuse you of that sort of closed
> mindedness, and if it came across that way, I apologize.
I didn't think you did accuse me of closed mindedness (other people
have, at times, and they have sometimes done so fairly. I can be rather
rigid in my opinions, or the way I express them). I was just trying to
clarify a little.
> There are
> many people, though, who have heard a rule, and gosh darn it, they're
> going to apply it, no matter what. Unfortunately it seems to be
> prevalent with people who are in charge of writing and enforcing
> coding standards.
>
With coding standards, as with any other set of rules, there is always a
balance between having a clear and consistent rule set and having
flexibility. Sometimes the consistency outweighs the details of the
rule, other times the rule might be too strict. Usually in coding
standards it is a good idea to have different levels (you /must/ do
this, and /should/ do that) and to have procedures for breaking the
rules ("should" rules can be broken but you must comment the break in
code, breaks of "must" rules need written permission from the program
manager).
> That being said, I don't think we're really disagreeing on all that
> much.
>
Agreed. I think we are both against banning "goto" merely because it is
trendy to hate it, or because Djikstra wrote a paper against it. We are
both looking for ways to write the code in a clear, logical and
maintainable fashion, and we are both expecting to use good tools and
newer language standards in order to get that without a cost in
efficiency. We just disagree a little on when "goto" might boost code
clarity, and when it is a detriment - and that is likely to be from
different experiences and different types of code.
>
>> And I agree that occasionally a goto may be a clear way to write code -
>> it simply hasn't been a clear way to write any code that /I/ have had to
>> write.
>>
>> I do think, however, that if you have a function for which a goto would
>> seem the clearest solution, then it is likely to be an overly complex
>> function. Functions with too many paths, branches, loops, etc., are
>> often hard to analyse (mentally, formally or with analysis tools) to be
>> sure all the paths and loops work as expected. A "goto" should always
>> be treated with suspicion - either it is a poor solution to the problem,
>> or perhaps you need to change the problem.
>>
>> I am sure there are some types of coding situations where goto is
>> considered a reasonable choice - I just don't meet these situations.
>
>
> Different people will disagree about issues of style and clarity.
> That's inevitable. Take the endless brace-style discussions
> (please!).
Yes. There is one correct way, that I use, and a number of wrong ways
that some other people use :-)
>
> But if I come work on one of your projects, I'll follow your project's
> standards. And perhaps I might struggle a bit in some of the
> (occasional) cases where I might consider a goto, or if your standards
> for routine length might be a bit shorter than ours, or whatever,
> simply because that somewhat changes the idioms I'm used to using
> every day.
>
> And if you come work on one of mine, I'll trust you not to run off and
> refactor everything that doesn't meet your preferences.
Indeed. Consistency is very important.
There are times when a big refactoring is appropriate, but you need good
reason for it - changing brace style, for example, is not such a reason.
>
> And we can both (good naturedly) grumble about the wrong-headedness of
> the other approach at the water cooler.
>
Yes - and I view c.l.c. and c.l.c++ as virtual water coolers!
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-01-27 01:50 -0800 |
| Message-ID | <86v9oxgrea.fsf@linuxsc.com> |
| In reply to | #71600 |
Robert Wessel <robertwessel2@yahoo.com> writes: > On Sun, 26 Jan 2020 14:58:45 +0100, David Brown > <david.brown@hesbynett.no> wrote: > >> On 26/01/2020 13:44, Bart wrote: >> >>> 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. > > I don't think efficiency is a main concern here, or even an important > one. Rather some uses of goto are, at least IMO, clearer than many of > the alternatives. The error handling and nested-loop escape being two > common ones. C++/RAII mostly removes one of those. > > Certainly everything can be written without gotos, I just don't think > that's always the clearest way to write the code. "Clarity" being a > somewhat subjective determination, of course. A bit of code in an > unfamiliar idiom, even if simpler, can be less "clear". > > Still, gotos should be used quite sparingly. And uses should avoid > the "spaghetti" code of the distant past. > > On the other hand, this is a bit of a tempest in a teapot. When > Dijkstra wrote "Goto considered harmful", his context was unrestricted > branching across large monolithic programs (sometimes 10's of KLOCs). > The problems that introduces are just not possible if you have > reasonably sized routines. I'm not suggesting that unrestricted > branching across a 50 line routine is a good idea, but he'd never have > written that paper to deal with those issues. You just cannot have > the morass you get from a bunch of labels in a chunk of code > referenced by dozens of gotos, many from multiple thousands of lines > away. > > I just think people have gone a bit overboard with the idea, so that > it's ended up as "if there's any way to avoid a goto, do so" (which we > know is actually always possible*), rather than focusing on clarity. I give this posting my vote for the best commentary in the thread.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2020-01-27 08:21 +1300 |
| Message-ID | <h9676lF25s3U12@mid.individual.net> |
| In reply to | #71591 |
On 27/01/2020 01: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: 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). These points have already been covered in this thread, why bring them up again? -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-01-25 20:14 +0100 |
| Message-ID | <r0i43c$8sk$2@dont-email.me> |
| In reply to | #71567 |
On 25/01/2020 12: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..." > I have never used "goto" in C++ code. Does that help? (It's easy to mix up when the discussion is about C, when it is about C++, when it is about either, both, or a comparison of the two. It has certainly got jumbled in this thread.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-01-25 20:12 +0100 |
| Message-ID | <r0i3un$8sk$1@dont-email.me> |
| In reply to | #71559 |
On 25/01/2020 02:19, Bart wrote:
> 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.)
My code (especially my C code) is almost invariably written for
customers, and not something I can publish. Most code written by most
programmers is like that.
("Readability" is a somewhat subjective quality, and always a balance
between different factors, so I don't want to sound like my way of
coding is the only way. I code in the way that gives the best
readability for the type of programming tasks I handle, with
consideration for the customers and colleagues I have - I don't say my
styles and habits are universally applicable. Well, not /all/ of them,
anyway.)
>
> 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).
>
You can repeat it until you are blue in the face - it is irrelevant for
any purpose other than showing that at least some large C projects use a
lot of gotos. Personally, I am not particularly fond of some of the
coding styles I have seen in the Linux kernel.
> 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.
You can probably take a guess at how much I use "longjmp". I don't
believe I have ever seen a case where I thought it was a remotely good
idea. (I am not a great fan of exceptions in C++ either - certainly not
for the kind of coding I do on small systems where failure is not an
option. They are okay in Python, but that's a different kind of language.)
C++ RAII through constructors and destructors is what avoids many of the
coding problems that are sometimes solved with "goto" in C. It is not
exceptions.
>
> 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.
A difference here is that makefiles are not part of the C or C++
languages, while macros are. I don't know why you would mix these.
>
> 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 | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-01-27 07:48 -0800 |
| Message-ID | <86mua8hpd9.fsf@linuxsc.com> |
| In reply to | #71519 |
Christian Gollwitzer <auriocus@gmx.de> writes: > Am 22.01.20 um 12:26 schrieb boltar@nowhere.org: > >> I have paint to watch drying instead. Nice idiom >> >> No doubt it comes from the same ivory >> tower that claims gotos should never be used. > > Ivory tower, for sure? We have while, for, break, continue, return, > and exceptions. All these compile to some sort of goto in machine > code. > > 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. I won't make any arguments for a good use case for goto, but I have some facts to report that might be of interest. I looked for uses of goto (using grep -w) in a convenient corpus of C and C++ code - mostly open source software packages, about 250 million lines. By coincidence there were close to the same number of lines of C source as lines of C++ source. The number of goto's in C code was about five times the number of goto's in C++ code. However, considering just those files that had at least one 'goto' in them, the rate of using goto was about the same in C++ as in C: just under 13 per 1000 lines in C++, just over 14 per 1000 lines in C. (Remember, that is looking only at files that use 'goto' at least once.) In the corpus as a whole, the size of a source file in lines (measured by 'wc') was on average about 20% higher for C code than for C++ code. Considering just those files that had at least one 'goto' in them, the sizes of source files was on average about one third more for C++ than it was for C. Switching now to personal experience, I am not dogmatic about never using goto but it almost never comes up in code that I write. That applies to C as well as C++. I do remember a case that came up several years ago (I don't remember if it was C or C++ but the same considerations would apply in both languages). I had an awkward loop of the "loop and half" variety. I tried perhaps half a dozen different ways of writing it, but all those I tried seemed unsatisfactory in some way. The alternative that seemed the best of the different ways I looked at rolled the loop half way down so the exit was at the bottom but had to be entered somewhere in the middle. Of course that meant using a goto. The result still wasn't something I was really happy about; it just seemed better than all the other ways that I tried. And that I think is a good principle for goto generally: explore as many alternatives as reasonably feasible, and use goto only when all the alternatives look worse. That is my sense anyway, fwiw.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-02-18 18:46 +0100 |
| Message-ID | <r2h7u3$jvv$1@news.albasani.net> |
| In reply to | #71519 |
> 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 MISRA:C 2012 allows gotos if they go forward.
[toc] | [prev] | [standalone]
Page 6 of 6 — ← Prev page 1 2 3 4 5 [6]
Back to top | Article view | comp.lang.c++
csiph-web