|
Hmmm , How About this,
I think you'll find the performance similar to your third method.
bool foo()
{
if ( AllocateStuff() || DoThis() || DoThat() )
{
CleanupError();
return false;
}
else
{
CleanUp();
return true;
}
}
I really do believe its preference at the end of the day,
Hey I have not used a While statement in years !
Regardz
Colin
|
|
|
|
|
What about this?
bool foo()
{
if (!AllocateStuff() || !DoThis() || !DoThat())
{
CleanupError();
return false;
}
CleanUp()
return true;
}
|
|
|
|
|
I can't imagine a single example, where I really want to use 'goto' 
--
Alex Marbus
|
|
|
|
|
I've never had to use goto in C++ or any other structured language, but back in the bad old days (1992-3) when I was a MUMPS developer, "goto" and other bizarre things like postconditionals on statements were used to construct some useful things that didn't exist within the language.
If I remember correctly, you could make a while loop out of an argumentless FOR loop, and a postconditional and you could make a do...while by doing something wonderfully baroque like this:
IF (condition) THEN FOR DO QUIT:(NOT condition)
.(loop body goes here)
You would use a GOTO in circumstances where you might use a "break" in C++, and in older code it was used to implement subroutines (functionality was later added to the language to make this unnecessary).
For what it's worth, IMHO MUMPS is the most horrible programming language in the world - my example is not true MUMPS because I've tried to improve its readability slightly in order to make the point. I'm not aware of any other languages in which you can write an infinite loop in three characters, two of which are invisible (F, space, space). 
Gavin.
|
|
|
|
|
So, if I understand correctly, goto is not a statement you should use in an (wanna-be) object oriented language such as C++
--
Alex Marbus
|
|
|
|
|
It's not an absolute "no go" (or "no goto"?). As someone else has pointed out with an example in a later post, there may be circumstances under which a "goto" is a sensible alternative. However, for almost all circumstances in which you might be tempted to use a goto there is a better structured alternative, and in the few cases where goto might actually be best, it is still worth thinking about a structured alternative just to avoid getting into the habit of using goto. This is because, like most things, goto is not necessarily bad in moderation - however, if you do let yourself be tempted, it is easy to let it get out of hand. Just say no! 
Gavin.
|
|
|
|
|
The goto statment can come in very handy when you need to execute some function-specific code frequently, for example 'abort on error' code, as in the following example:
object = object_create()
if (!object)
goto ExitWithError;
if (!DoSomeCoolThingWithObject(&object))
goto ExitWithError;
else
{
}
return TRUE;
ExitWithError:
ReportError("I had an error in function : CoolObjects()");
AddErrorToLog(-1, "I had an Error in function : CoolObjects()");
ShutDownServer();
return FALSE;
Although it would be possible to add the code each time, that would be more hassle to maintain, and creating a whole new function just for it is pointless. Using the goto statement is quick, easy, and in my opinion the correct way to handle the situation above.
David Wulff
dwulff@battleaxe-software.co.uk
|
|
|
|
|
What's wrong with try/catch/throw ? Stroustrup suggests this approach for exactly the sort of problem you state, even if it isn't to do with error handling.
Christian
The content of this post is not necessarily the opinion of my yadda yadda yadda.
To understand recursion, we must first understand recursion.
|
|
|
|
|
A try/catch/throw will still be more complex to write than what I have shown using the goto statement. The t/c/t approach would also require me to duplicate the 'abort on error' code.
David Wulff
dwulff@battleaxe-software.co.uk
|
|
|
|
|
The complexity level would actually be the same (at least in my opinion). Simply place a try statement at the top of the function, close it with a catch containing the "ExitWithError:" code at the same place you put that code. Then replace your "goto ExitWithError;" lines with "throw xxx" statements. This would not require duplicating the "abort on error" code.
The try/catch alternative can actually improve things, too. If you need to pass information to the error handling code, you can just throw the information. With the goto statement, you'd have to manually create variables, set them before calling goto, and then check them in the error handling routine.
Anyway, goto isn't bad. I just think there are better ways, and that it is normally worth the effort to use the better way than the quick and easy way -- especially after you make those better ways into habits.
John
|
|
|
|
|
|
I agree totally, I just didn't feel confident to say so.
Christian
The content of this post is not necessarily the opinion of my yadda yadda yadda.
To understand recursion, we must first understand recursion.
|
|
|
|
|
A good time for use of goto's is a top down parser implementation. My instructor at school called this 'blood sweat and tears' parsing. It is not that it is pretty or anything, it just can reduce the amount of code you gotta write, doesn't use any recursion, and is not that hard to make readable.
|
|
|
|
|
Have just run search for gotos in .CPP files in the MFC/SRC directory. Found 99 instances 
|
|
|
|
|
Only because Microsoft uses goto's, it doesn't make goto's any better, or an excuse for using them.
Microsoft's programmers are only human, not programming-gods.
maXallion
"Is there any Tea on this Spaceship?"
- Arthur Dent
Maxallion's World
|
|
|
|
|
<- .. like it 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
