View Poll Results: How often have you used 'goto' in the last 5 years?
- Voters
- 111. You may not vote on this poll
-
February 15th, 2004, 06:10 PM
#46
Excellent explanation Andreas.
All the buzzt
CornedBee
-
February 15th, 2004, 07:18 PM
#47
Originally posted by j0nas
Sam and others... Yes, maybe I did take many of the replies too seriously or didn't express myself well enough. I have problems with replies, in "open ended" questions, that sound like he or she is telling the pure truth. I'll try better next time.
I know it can be difficult for others to know how serious I am or am not. Sometimes it is difficult for me to know. For what it is worth, I definitely know that it is unlikely that another person will change their mind if someone else insists that their way is the only way.
I was trying to find a post somewhere in the first couple of pages to respond to on a couple of topics but I can't find what I was looking for. It is amazing that this has already grown to four pages.
I agree that try/catch is not the ideal solution. I prefer to use return codes for determining an error condition. However one advantage of try/catch is that it is part of the standard, so the compiler and other programmers expect it to behave according to the standard.
I can understand use of a goto for cleanup. Cleanup is a relatively inconvenient thing to deal with sometimes. Often we need to do something such as get an interface or open a file or allocate memory and we must do something else depending on what was done previously. If we get an error we must undo what has been done but only as much as has been done. There are many possible solutions and I am not describing all the details of using a goto for this but I do understand that a goto could be a convenient way to do the cleanup.
-
February 15th, 2004, 07:43 PM
#48
Originally posted by Yves M
Can you explain why you need goto in your case? It would be interesting to know.
Sure.
In C and the type of business I'm in, we often end up doing lots of sequential stuff: calling a function, if the function failed, goto cleanup. If you need to call, let's say, 8 other functions within a function, I rather use goto cleanup/fail than having 8 levels of indention. That's why I think goto:s make my C source code more readable, easier to maintain and therefore less buggy. If you also combine this with the good habit of always initializing local variables (at least pointers), you've created a very good foundation of a defensive programming style. My experience says that creating these simple "rules" of programming, helps less senior programmers to both maintain and add new functionality to existing code, without screwing up too much.
And yes, you can do all this without using goto, but that will cost you with more code and/or less readable code.
Occasionally, I've used another technique, the well-known do-while(0) method, instead of goto. That is fundamentally the same thing, but without using the goto keyword.
-
February 16th, 2004, 02:01 AM
#49
Originally posted by Andreas Masur
Well...this has become longer than expected...sorry for that...
Not at all Andreas. It's now early morning (UK time) and you've certainly got my brain into gear - but it's much appreciated! I think the RAII technique you described is similar to the principle of smart pointers, which I use quite extensively - but I'd never heard the term RAII.
Originally posted by Andreas Masur
'catch' areas can be react on specific objects or all exceptions:
Code:
catch(...) // Will react on every thrown exception object
catch(const CError &refcException) // Will only react on thrown 'CError' and derived objects
For my money, this is the only weakness of try/catch logic. The option:-
catch(const CError &refcException) // or whatever
can only be relied upon in code that you wrote yourself. Too many times I've come across documentation stating that function X throws an 'int' - which it probably did at one time - except that the code got updated but the documentation didn't. In fact, I think there's at least one example of this in MFC although I can't remember what it is now.
The upshot is that, when interfacing to someone else's code, it's usually better to play safe and stick with:-
catch(...)
because it catches any thrown exception.
Thanks to everyone who pitched in on this. I can't speak for everyone else but I've found it enormously enlightening!
-
February 16th, 2004, 02:35 AM
#50
Oh - one other question.....
Where the thrown exception object is a pointer - e.g.
Code:
catch(some_exception_object * pException)
is it always safe to assume that the object being pointed to will need to be deleted? - e.g.
Code:
catch(some_exception_object * pException)
{
. . . // do whatever needs to be done
delete (pException); // :confused: - Would this always be the case?
}
-
February 16th, 2004, 05:06 AM
#51
Originally posted by John E
I think the RAII technique you described is similar to the principle of smart pointers, which I use quite extensively - but I'd never heard the term RAII.
Yes, you are right...a smart pointer is following exactly this technique...
Originally posted by John E
For my money, this is the only weakness of try/catch logic. The option:-
catch( const CError &refcException) // or whatever
can only be relied upon in code that you wrote yourself. Too many times I've come across documentation stating that function X throws an 'int' - which it probably did at one time - except that the code got updated but the documentation didn't.
That is of course one of the biggest problems. However, that is not only a problem while using exception handling. But that is exactly one of the drawbacks, however, usually you can enclose you entry routine with a general 'catch(...)' to prevent crashing and allow a successful closage of the application.
The above description is even worse in regard to exception specifications. They are supposed to clearly indicate which type of exceptions will be thrown by a function. Nevertheless, this serves only documentary purposes since your above described problem counts here as well...
-
February 16th, 2004, 05:08 AM
#52
Originally posted by John E
Oh - one other question.....
Where the thrown exception object is a pointer - e.g.
Code:
catch(some_exception_object * pException)
is it always safe to assume that the object being pointed to will need to be deleted? - e.g.
Code:
catch(some_exception_object * pException)
{
. . . // do whatever needs to be done
delete (pException); // :confused: - Would this always be the case?
}
Yes...while throwing pointers around you usually have to delete them, nevertheless this kind of depends what the type of exception handling is supporting...
-
February 16th, 2004, 12:36 PM
#53
Actually it depends on how you throw the exception. If you throw it with
throw new CException("Error occurred!");
then you need to delete it.
If you throw it with
// global
CException globalException;
throw &globalException;
then you cannot and must not delete it.
In general, it is not a good idea to throw pointers. Stick with throwing temp objects and catching references, exception classes should be small anyway.
Oh, and in the MFC it's safe to assume you gotta delete the exception pointer.
All the buzzt
CornedBee
-
February 16th, 2004, 12:41 PM
#54
Originally posted by CornedBee
Oh, and in the MFC it's safe to assume you gotta delete the exception pointer.
Well...and failing in doing so in many examples...
-
February 16th, 2004, 01:19 PM
#55
I don't use a goto since the old times of BASIC.
Haven't you ever read the famous article "GOTO statement considered harmful" by W. Dijkstra? (may 1968)
-
February 16th, 2004, 01:42 PM
#56
I think Yves posted a link to it in another thread but although I followed the link, I couldn't find the goto comments !
What did he say (in a nutshell!) ?
-
February 16th, 2004, 02:05 PM
#57
Originally posted by Doctor Luz
Haven't you ever read the famous article "GOTO statement considered harmful" by W. Dijkstra? (may 1968)
Oh that sounds so familiar! I don't know if I read it but I know I have heard of that article. It was a part of the beginning of Structured Programming.
Go To Statement Considered Harmful
GoTo considered Harmfull
considered harmful
Perhaps someone can find the "‘Goto considered harmful’ considered harmful" article.
-
February 16th, 2004, 03:22 PM
#58
I like the conclusion in that last link - that it took several decades before everybody realsed that in fact, both sides were wrong...!
-
February 16th, 2004, 03:25 PM
#59
Originally posted by John E
I like the conclusion in that last link - that it took several decades before everybody realsed that in fact, both sides were wrong...!
Well..sometimes it takes some time...
-
February 16th, 2004, 03:25 PM
#60
Dijkstra's article
In [2] Guiseppe Jacopini seems to have proved the (logical) superfluousness of the go to statement. The exercise to translate an arbitrary flow diagram more or less mechanically into a jumpless one, however, is not to be recommended. Then the resulting flow diagram cannot be expected to be more transparent than the original one. [1]
This is good argument for the pro-goto people
Get this small utility to do basic syntax highlighting in vBulletin forums (like Codeguru) easily.
Supports C++ and VB out of the box, but can be configured for other languages.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|