I think that the anti-goto rhetoric is largely a leftover from the bygone era when many programers learned to program in asm or basic where gotos and jmps were natural. People who started with C or higher level languages usually use higher level flow control primitives because, for most code, they're easier to write, maintain, and think in.

That's what longjmp() is for.
(/me is mostly joking)

edit: first paragraph was edited for clarity

If you're using the exact code that you've just put in those last three examples, then no, that won't work. That's just skeleton code to show you examples of how a loop can be done.

You want something like this:

I didn't notice you were counting down i to give the player 20 moves.

Here's a version that works exactly like the executable you included. I've restructured the program completely though, and changed parts that could be made simpler.

You were also using the key[] array incorrectly, which is why you were getting multiple rolls each time you pressed a key.

main.cpp:

player.h:

player.cpp:

This new run_game() function "fixes" the problem of it rolling when other keys are pressed. I'll leave it up to you to figure out how to only display information when M is pressed.

WOOOW !!!!! Run very good - I must seeing through very attentively - thank you LennyLen

--------------------------
ups - pawn after throw bone doesn't go after right fields - I tried change it but only when I use "goto" was okay

LennyLen somewhere is little mistake - pawn after throw bone doesn't go after right fields - I tried change it but only when I use "goto" was okay

Gee...

This sounds almost like the program I provided earlier to you, kosmitek, before you added the "player" class. Can't for the LIFE of me figure out why that code couldn't be used... It was re-written to be very understandable, use the exact same keys, handle the exact same logic...

Why not just extend what was already written for you and use that? It's not as if the code doesn't compile...

LennyLen, I don't know if you saw that earlier post or not (in the other thread, no less), but you may be able to use it. If not... shrug.

OK... you guys are posting about how GOTO is ugly and hard to read, and then post this as some sort of counter-example:

for(multiset<CObject*, SSortObjects>::iterator it = CObjectList::o().begin();it != CObjectList::o().end();) // loop through STL-multiset (could be any other container as well)
      if ((*it)->get_x() + (*it)->get_w() < CCamera::o().get_x()) // check, if some statement about the object is true and delete it
      {
        it = CObjectList::o().erase(it); // delete one object from the container
      }
      else
        it++;

I mostly use GOTOs for function-level error handling. Setting a flag, checking it in multiple points to break a loop/nest is slower and less efficient than a goto.

I think in my program must be "goto", without "goto" my program isn't run good.

LENNY LEN - YOUR IDEA WITH 3 files: main.cpp; player.h; player.cpp, one table; and globall variables ARE WONDERFUL - WITHOUT THAT I MUSTED (MUST IN THE PAST ?) WRITE EVERYTHING IN ONE BIG FUNCTION AND NOW I HAVE MANY LITTLE FUNCTIONS - THANK YOU - THIS IDEA IS VERYYYYY GOOD - THANK YOU LENNY LEN FOR YOUR IDEA - I USE YOUR IDEA (but I had use "goto") AND I ADD GLOBAL TABLE - ONLY ONE TABLE !!! - THANKS YOU !!!!!!!!! YOU ARE WONDERFUL - THANK YOU !!!!!

Yeah I saw it. Most of my code was actually from when I rewrote the program last time kosmitek posted about it a few weeks ago.

The real problem was that you didn't explain very well what you were trying to do, and it's hard to tell from your code exactly what you are doing.

Now that I'm pretty certain that I know what you're trying to do, I've changed the logic to reflect this. I've attached the working code (the changes were to the run_game() function) and an executable. There's still no need for goto.

edit:

Don't rely too much on global variables. They certainly have their uses, but if you have too many of them, it makes the program harder to follow and less modular. There's usually a more elegant solution.

now it runs ideal WITHOUT "GOTO" - LENNY LEN YOU ARE GENIUS !!!!!!

Thanks for the pretty code Bob, i didn't know you could handle it that way!

What i previously did:

//fl...ake is a vector iterator of the same type as snow
//snow is a vector
for(fl = snow.begin(); fl!=snow.end(); fl++){
    if(fl->dead()){
        snow.erase(fl);
        fl--;
        }
}

Is this wrong or bug prone?