on goto
in [General Programming]
|
From: James Dow Allen on 24 Apr 2010 23:22 On Apr 25, 10:17 am, James Dow Allen <jdallen2...(a)yahoo.com> wrote: > PS: Your newswriter seems to have clipped the link, Daniel, which > I then had to hand-enter. I think Google Groups would have gotten > it right, so you may want to switch to that: :-) Yes, Google's link did work. And yes, it was tongue-in-cheek of me to suggest you switch to Google. :-) Nevertheless I will point out that some pedants delight in ranting at every Google bug. When Google gets it right and their news software doesn't, they seem to view the non-Google foibles as "treasured souvenirs of a bygone superior era." :-) Just saying.
From: Juha Nieminen on 25 Apr 2010 01:09 In comp.lang.c++ Ali Karaali <alicpp(a)gmail.com> wrote: > I use goto to break nested for loops and I can't see a > reason to ban goto. No. The correct keyword for breaking out of nested loops (in C++) is 'return'. If you are using 'goto' for that purpose, you are doing it wrong. "It's not the same thing". Precisely. If you design your code such that you can always use 'return' to break out of nested loops, it will become cleaner and easier to understand. I have been programming in C++ both professionally and as a hobby for over 10 years, and I have never got into a situation where 'goto' would have been a tempting alternative because of being a simpler and more straightforward solution than something else. It just doesn't come up. I don't remember ever having written a 'goto' in the last 10+ years. It's not a question of banning 'goto'. There is no *need* for 'goto'. And if you code in such way that you just don't need it, your code will become cleaner in a completely natural way.
From: spinoza1111 on 25 Apr 2010 01:21 On Apr 25, 1:06 am, "Daniel T." <danie...(a)earthlink.net> wrote: > spinoza1111<spinoza1...(a)yahoo.com> wrote: > > On Apr 24, 11:46 pm, "bartc" <ba...(a)freeuk.com> wrote: > > > "Daniel T." <danie...(a)earthlink.net> wrote: > > > > Ali Karaali <ali...(a)gmail.com> wrote: > > > > > > I use goto to break nested for loops and I can't see a reason to > > > > > ban goto. > > > > > I'll give you a reason to ban goto. This is a line of BASIC code: > > > > > 90 x = 5 > > > > > Now, I ask you, where is the line that was previously executed? Is > > > > it directly above line 90, is it directly below it, or could it be > > > > anywhere in the program? Because of the goto statement, simply > > > > because an unstructured "goto" is possible in the language, you > > > > have to analyze the entire program to know the answer. If we ban > > > > the use of "goto", we can confidently know exactly what line of > > > > code comes before line 90. > > > > Goto's at least are usually confined to the same function; if the > > > function is smallish, you don't have to look far to match a goto > > > with a label. > > > It's not a question of how far you have to look. It is a question of > > minimal preconditions. If you have a go to even in a small program, > > the code that follows it has a larger set of preconditions. > > Could you go into more detail? Maybe with some examples? For every go to there is a label. For each place that control "comes from" there is a separate bundle of facts that cane be true.
From: Alexei A. Frounze on 25 Apr 2010 03:46 On Apr 24, 3:33 pm, James Kanze <james.ka...(a)gmail.com> wrote: > On Apr 24, 10:26 pm, Phil Carmody <thefatphil_demun...(a)yahoo.co.uk> > wrote: > > > Tim Streater <timstrea...(a)waitrose.com> writes: > > > I haven't used a goto since 1978 (when I stopped writing > > > FORTRAN). > > Me neither. > > > I'm with Knuth. > > In other words, if goto makes the code simpler, it means that > you haven't found the correct expression of the algorithm. > > And of course, the problem isn't with goto, per se. It's with > the way it is used. But because it can be abused so badly, > modern languages (including C and C++) provide all of the > necessary structures (and then some) so you don't have to use > it. I wish there were distinct breaks for loops and switches as well as multi-level breaks for nested loops. goto's at times are the least evil since they don't require you to implement extra variables to break out of nested loops and they help to simplify function cleanup code (where resources are being freed on various conditions). > > I've reviewed patches and told the submitter to just convert > > all his jumble of 'structure' into nice clean goto statements > > many times this year. I don't use it for my own code, but > > $DAYJOB has a clear coding style that recommends goto in many > > situations. If goto has made your function unreadable, it was > > probably too big and unreadable anyway. > > If goto seems necessary, it's because your function is too big > and unreadable. But you don't want too many trivial functions either for you won't see the forest behind the trees. There should be a certain balance, subjective, of course, but it's not like goto's are evil no matter what. If they are evil, let's remember about pointers, which require a lot of care. And about horrible type conversions, where you can't even safely compare a signed int and an unsigned int (which is an absurd thing, IMO). And then about non-portable things, about implementation- defined/specific and undefined behavior. Now we're talking. goto is just nothing compared to all of that. :) Alex
From: Alexei A. Frounze on 25 Apr 2010 04:07
On Apr 24, 10:09 pm, Juha Nieminen <nos...(a)thanks.invalid> wrote: > In comp.lang.c++ Ali Karaali <ali...(a)gmail.com> wrote: > > > I use goto to break nested for loops and I can't see a > > reason to ban goto. > > No. The correct keyword for breaking out of nested loops (in C++) is > 'return'. If you are using 'goto' for that purpose, you are doing it > wrong. Now, let's consider C (or C++ where this function has to explicitly free up some used resources or do some other cleanup). The objects won't get freed here automatically by the magic of the destructor call generated for you by the C++ compiler. You could implement the cleanup code in several places of that function as block operators ending with a return, but very often these blocks are to a certain degree duplicates of one another. And it's not just the source code bloat that's bad, it's also us making a trap for ourselves because one day we may modify the function and forget to modify one or more of these cleanup block operators in it. > "It's not the same thing". Precisely. If you design your code such that > you can always use 'return' to break out of nested loops, it will become > cleaner and easier to understand. > > I have been programming in C++ both professionally and as a hobby for > over 10 years, and I have never got into a situation where 'goto' would > have been a tempting alternative because of being a simpler and more > straightforward solution than something else. It just doesn't come up. > I don't remember ever having written a 'goto' in the last 10+ years. > > It's not a question of banning 'goto'. There is no *need* for 'goto'. > And if you code in such way that you just don't need it, your code will > become cleaner in a completely natural way. Surprisingly, my code is pretty clean with gotos, which, btw, I use just for almost exclusively 2 things: - breaking out of nested loops (not always, if I can do that w/o writing more than two lines of code, I don't use goto) - jumping to the common cleanup code at the end of the function when I detect some error I get by without goto in almost all other situations. I don't see what's not natural here. It's a clearly written and structured code, that is easy to follow, without surprises, without bloat. Of course, if you never need to do any cleanup or you never check error conditions or rely heavily on C++ exceptions, the 2nd use may be just unnatural to you as it is to me since I'm programming C, mixed C and C+ + and I often have to deal explicitly with resource allocation. Alex |