Jump to content
  • Advertisement
Sign in to follow this  
Alpha_ProgDes

Is this a bad use of GoTo?

This topic is 2622 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

[source lang="vb"]
Function fsmHeater()
Dim Timer As Integer 'Initialize
State0:
Off (oHeater)
Off (oAlarm)
'---
WaitFor(Temperature() < 84)
State1:
On (oHeater)
Timer = GetmS()
'---
Select Event
Event Temperature() > 85
GoTo State0
Event GetmS() - Timer > 6000
GoTo State2
EndSelect

State2:
Off (oHeater)
On (oAlarm)
'---
WaitFor(Input(iResetButton))
GoTo State0
End Function
[/source]

Is this a good use of GoTo? This code is supposed to mimic a FSM. Personally, I see nothing wrong with it. Given the function is pretty short. But I wonder if this approach should be avoided: because of a better solution, or just because GoTo is the spawn of evil itself.

FSM Link

A snippet from page:

Notice that when an event match happens the line of code following the event condition is executed. In this program that is a GoTo. In many circles GoTo is considered to be bad programming. Not so in coding FSMs; GoTo allows you to move from place to place in the code in a way that echoes how the state diagram transitions from place to place. [/quote]

Share this post


Link to post
Share on other sites
Advertisement
Depends on how WaitFor is implemented. I might be more inclined towards more of an event driven model because it's easier to modify/extend/test, but this is pretty clear and nice (despite my disdain for all things goto).

Share this post


Link to post
Share on other sites
You could also use the equivalent of a switch statement
warning heavy sudo code


void fsmHeater()
{
bool AreWeDone = false;
int State = 0;
while(AreWeDone == true)
{
switch (State)
{
case 0:
{
Off (oHeater)
Off (oAlarm)
'---
WaitFor(Temperature() < 84)
}break;
case 1:
{
On (oHeater)
Timer = GetmS()
'---
Select Event
Event Temperature() > 85
State = 0;
Event GetmS() - Timer > 6000
State = 2;
EndSelect
}break;
case 2:
{
Off (oHeater)
On (oAlarm)
'---
WaitFor(Input(iResetButton))
State = 0;
}break;
}

}
}

Share this post


Link to post
Share on other sites
Personally, I don't like it. I was going to suggest pretty much doing the same thing as yewbie did. If you have a game loop then all you should need to do is set a variable to the state you want and when the next loop comes around the initial switch (select) statement will catch the new state and do what you wanted; therefore the goto statements are not needed.

I just don't like goto statements... sorry

Share this post


Link to post
Share on other sites
off-topic: wow. the editor is really bad. I hope this new forum upgrade fixes this.

on-topic: that's not bad either. doesn't look much different from the GoTo really.

Share this post


Link to post
Share on other sites
In this instance, given the function in question it's fine.

However given that most FSMs are generally written in a 'do something, optionally set next state, return to caller' manner a goto is unlikely to be a good match in the majority of cases when using/writing a FSM.

Share this post


Link to post
Share on other sites
Also, I just read that first page of the link you provided on FSMs and I have to say I completely disagree with the following statement:

Notice that when an event match happens the line of code following the event condition is executed. In this program that is a GoTo. In many circles GoTo is considered to be bad programming. Not so in coding FSMs; GoTo allows you to move from place to place in the code in a way that echoes how the state diagram transitions from place to place.[/quote]

You can accomplish exactly what you need to do in a Finite State Machine without ever using a goto statement! But then again, what do I know... I'm a noob at all this stuff too :)

Share this post


Link to post
Share on other sites

Is this a good use of GoTo? This code is supposed to mimic a FSM. Personally, I see nothing wrong with it. Given the function is pretty short. But I wonder if this approach should be avoided: because of a better solution, or just because GoTo is the spawn of evil itself.


FSMs have been traditionally implemented using a switch statement (see above).

The reason lies elsewhere. A FSM is a graph, which can be represented using a matrix. Since all but the most trivial FSMs contain considerable number of states and might be machine generated, using state and action tables is by far the simplest way to implement them.

It has less with style but more with pragmatic approach.

There is another benefit of using state as external variable. One state advancement can act as generator or yield operator. Or put differently, if you call your state machine via some function "advance()", it will move one state, then return, allowing to take action, rather than just having to modify the internals of FSM during development.

In language parsers there is usually nextToken() function, which is a state machine that will return in the middle of processing. Such workflow is typically not possible using gotos.


For fixed FSMs, such as interpreters or VMs, gotos will often be machine friendliest and fastest way to implement them. They are used by JS VMs, for example. They are simply a natural fit, since a FSM is nothing but jmps and gotos translate to those directly.

Share this post


Link to post
Share on other sites
It's been a looooooooonnnnnnnnggggggg time since I have used a basic derived language, so excuse my ignorance, but does BASIC have a viable switch statement?

Share this post


Link to post
Share on other sites

It's been a looooooooonnnnnnnnggggggg time since I have used a basic derived language, so excuse my ignorance, but does BASIC have a viable switch statement?


Yes and I believe it's a "select statement" in basic

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!