|
goto is a hack. VB is a scripting language, which is a euphamism for a hacking language.
no paradox.
real languages use throw and catch.
|
|
|
|
|
Bwhaahaahahahaa !!
Um.... is this person trolling to make *my* point ? ( VB sucks )
I can't imagine choosing to use a language that does not support inheritance, for starters, and agree with the other person who posted on this thread ( in fact this has been discussed below as well in relation to goto vs. try/catch/throw )
Christian
The content of this post is not necessarily the opinion of my yadda yadda yadda.
To understand recursion, we must first understand recursion.
|
|
|
|
|
.. so I guess you can't have done much programming when Fortran 77, Assembler and so on where the only games in town.
I agree with you VB is getting a little long in the tooth and being pushed further than it aught to go, but I'd have to say it filled/s a purpose.
So you'll be seconding my request for a vote on whether or not VB (dot-Net or not-Net) makes an appearance on here. Thank you so much 
Al
ATL Student 
|
|
|
|
|
.. Ever tried VB 'error handling' without it?
ATL Student
|
|
|
|
|
F77.NET and ASSEMBLER.NET are rendered useless without GOTO.
|
|
|
|
|
Bwahahaha! I was waiting for a comment on FORTRAN 
So the issue is settled then!
cheers,
Chris Maunder
|
|
|
|
|
I can't find an example of goto ?
I know I am old, Writing code longer than some of the folks here have been breathing,
And I have never used a GoTo or goto or Goto ;
( outside of ASM code that is ).
I am unsure why I would wish to program in such an unstructured way,
Regardz
Colin
|
|
|
|
|
You can use goto in place of do/while/for; you can use it to quickly exit to cleanup code at the end of a function; you can use it to create the most horrible switch statement replacement ever; and you can use it to give your code reviewers coronaries. What more could you ask for in a statement!
One thing I have used a goto for is for cleanup. I could have used exceptions, but I wanted performance and was just not in the mood for try/catch statements (I know, I'm fickle).
Instead of:
bool foo()
{
if (!AllocateStuff())
{
CleanupError();
return false;
}
if (!DoThis())
{
CleanupError();
return false;
}
if (!DoThat())
{
CleanupError();
return false;
}
CleanUp()
return true;
}
or you could use
bool foo()
{
do
{
if (!AllocateStuff())
break;
if (!DoThis())
break;
if (!DoThat())
break;
CleanUp();
return true;
} while (false);
CleanupError();
return false;
}
OR you could use
bool foo()
{
if (!AllocateStuff())
goto error;
if (!DoThis())
goto error;
if (!DoThat())
goto error;
CleanUp();
return true;
error:
CleanupError();
return false;
}
cheers,
Chris Maunder
|
|
|
|
|
OR you should use constructor/destructor approach.
bool foo(){
Cleaner c;
if(!AllocateStuff())
return false;
if(!DoThis())
return false;
if(!DoThat())
return false;
return true;
}
Cleaner destructor is equivalent of CleanUp() method.
You can also use Cleaner constructor instead of AllocateStuff().
|
|
|
|
|
So great... Now I have to write a whole other class called Cleanup. Why can't I just use goto?
|
|
|
|
|
Wow. Instead of
void CleanUp(){
... something
}
you have
class Cleaner { ~Cleaner(){
... something
}};
Anyway, the only reason of using this syntax is to make foo function more readable and easier to expand and maintain.
|
|
|
|
|
And also for a case when an exception occurs in DoThis or DoThat.
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
