Printable View
I have used goto occaisionally mainly to jump out of deepish nested loops as it avoids extra comparisons and can save a flag variable or two.That is the only use I have found for goto. I also believe that if goto is used properly it is also safe with regards to exceptions. If you jump out of a scope the destructors that need calling get called. I'm fine with that once in a while.
Hi, it's me again, the great goto-fan man...
It's very interesting to see that people that have never used GOTOs, also have most arguments against using them. It my sound logical at first sight, but I'm wondering where did they get all these con-arguments from, when they've never used GOTO?!?!Have all of you read Dijkstra's famous paper Go To Statement Considered Harmful?
I doubt all of you have picked your goto dislike from his paper. It would be interesting to hear where all the others have gotten it from. Was it in school, on a programming course or by a colleague maybe?
I can very well understand people that choose to not use goto (at least in C++ where you have exceptions), but what I don't understand is this religious anti goto talk... especially from those of you that don't understand its usefulness and probably never will.
/Jonas
For about 20 years I was a COBOL maintenance programmer. I have seen a great variety of code. I have seen some really ugly spaghetti code. Usually when gotos are used, the program is a mess. I dislike gotos because I know they are usually associated with messy code. It is the frustration of dealing with such stuff that I get an emotional reaction to the idea of gotos.
Management that does not know what they are doing and think they are saving money can allow programs to grow into a huge mess. One credit card company had a main update program that was so huge that it was continually modified by multiple programmers at a time. Another credit card company was forced to modify all their credit card software to process multiple companies when the software was originally written to support credit cards for just that bank had to be modified when the law forced them to. Situations like that cause software to be a mess and gotos can make the work much worse.
So I think I am justified in feeling the way I do. I think people need to anticipate that there are some programmers that have had experiences with gotos that will make it impossible to get them to listen to anything you say in favor of gotos, no matter how reasonable you might be.
When Strutured Programming was new, I attended a presentation of it. In the handouts was a sample program written with gotos and another version of it written as a strutured program. The first version was difficult to understand; the structured program was easy to understand. I am sure that programs you, Jonas, wrote would be as easy to understand as possible but use of a goto just opens a door I don't want open.
I have learned to program roughly 6 years ago, and I have been taught that goto was a devil. For that reason, I learned to not use it, and everytime I faced a problem, I found a solution without resorting to goto. Of course, I learned C++ right away, so I always had the tools to avoid goto...
My 2 cents
Well, my goto experience is based on BASIC, assembler and VB. I extended some existing x86 assembler program (some 10k lines) at a company I worked as a summer job. Part of it was pretty well written, but other parts were just 'random jumping around'. It took much more time trying to understand what the program flow was than to write the extension. But well, assembler does have an excuse.
Currently, in addition to programming in C++, I also maintain a pretty big VB codebase (also some VBA, but that's another matter). I'm not saying that the programmer who originally wrote it is bad, but in some places the code really is a mess, compounded by extensive use of gotos (forward and backward). It's hard to figure out what kind of program flow to expect and what kind of run-time characteristics the thing has. It's not only the fault of the gotos, but they do contribute quite a bit to the fact that it's unreadable.
That doesn't mean that the people who don't use it have never seen or had to maintain code that does use it.Quote:
It's very interesting to see that people that have never used GOTOs, also have most arguments against using them.
ditto, please serve me up a big plate of steaming spaghetti...one of the reasons I lean towards semi violently against ;) but then don't blame the game, blame the player.Quote:
Originally posted by Yves M
That doesn't mean that the people who don't use it have never seen or had to maintain code that does use it.
If you have to use gotos, this is one of the case that justify it´s use, you can change (on this case) the pure goto to use setjmp and longjmp, they made a "structured goto". More readable safe and legible. I don´t know exately if these instructions are on stardard but they are a elegant substitute for gotos.Quote:
Original posted by improving
I have used goto occaisionally mainly to jump out of deepish nested loops as it avoids extra comparisons and can save a flag variable or two.That is the only use I have found for goto. I also believe that if goto is used properly it is also safe with regards to exceptions. If you jump out of a scope the destructors that need calling get called. I'm fine with that once in a while.
Rabelo
Actually they are far more dangerous and applicable only where you need "rescue moves", such as escaping from recursive descent parsers.
Could you please explain me why are they more dangerous????
Rabelo
Unlike goto, they don't honor any language rules. This is especially bad for constructors and destructors, which don't get called.
I thought we are talking about C, C++ of course there is no necessity of goto at all, since try and catch do this job very well.
Setjmp and longjmp do honor the language rules, they form a structured block:
the plus of this struct is that there is no label, so it is much more manangable.Code:main()
{
if setjmp("blablabla")
{
{
{
{
{
......
{
....
....
if (unrecouvereble error occurs here....)
{
longjmp("blablabla")
}
}
}
}
}
}
}
else
{
wherever lonjjmp is called
the control falls in this point....
clean the house and exit;
}
}
}
This is probably an obvious question (but I've never actually used longjmp). Assuming the longjmp line was veentually reached, where would it jump to?
It jumps to the inside of the setjmp function. The difference is this: on return of a normal call to setjmp the return value is 1, on return when longjmp jumped into it the return value is 0.
But they don't necessarily form a structured block:
The two can be totally unrelated. Of course, this would be bad design, but it is possible. Worse errors are possible than with any other part of C except perhaps pointers. You can jump anywhere, from anywhere. You could even reuse jump buffers!Code:void somefunc()
{
setjmp("bla");
}
void otherfunc()
{
longjmp("bla");
}
This design for setjump is like you said, very very bad. You may think in terms of scope instead of functions.
Wherever lonjmp is called inside the setjump scope the block of the else is executed.Quote:
originally posted by John E
This is probably an obvious question (but I've never actually used longjmp). Assuming the longjmp line was veentually reached, where would it jump to?
Rabelo]
Well it's a bit rare.
I used one a few years ago when doing some work on mixed C/inline-assembler operating system design in order to create a label which was visible within both languages.
For normal C/C++ programming it is almost always the case that something went wrong with the fundamental software architecture if a a developer is strongly motivated to use a goto statement. And this sometimes mandates the usage of the programming idiom.
Whatever...
Sincerely, Chris.
:cool: