• Advertisement
Sign in to follow this  

how can I restart a loop: c++

This topic is 2300 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

Hi. One thing i can't figure out is how to restart(not break) a loop while i'm in the middle of it. This is just a solution to one of my problems because i couldn't get 2 SDL events working in my main loop. Note the i cant just do a while loop aroudn the whole thing because i only need to separate parts of the code with a restart.
thanks for reading.

Share this post


Link to post
Share on other sites
Advertisement
I feel I am not doing you a favore by providing you with an answer, but:

for ( int i = 0; i < 40000; ++i ) {
if ( restart ) {
i = -1; // Goes to 0 after the ++i.
}
}



This is extremely clunky and in my entire life I have never needed to use this.
There is always a better way, and you should be looking at why you need to use this type of hack to fix whatever problem you are having.
Assuming this is what you meant by "restarting a loop".


L. Spiro

Share this post


Link to post
Share on other sites
Factoring the code into separate functions/data structures should allow you to "restart" the loop by placing it inside another loop. Can you show us the code?

Share this post


Link to post
Share on other sites
I would probably do it with a GOTO statement with a nice clear label like 'goto RESTART_HERE;' (and the label RESTART_HERE: above the FOR statement of course)
which cant be any less obscure/mystifying to what its doing than most other ways of coding it.

And since the whole context inside the loop is probably blown (OP asking to restart the loop without any other qualifying specification)
then the cries of 'it will screw up the compilers optimization for the statement blocks' likely wont be true in this case.



Oh and depending on whats inside the loop (like lots of nesting fun) and how entangled the restart logic case is then multiloop exiting logic
can get very very ugly and complicating the coding for the 'goto-less' solutions (flag testing on every nested loop, exit coding if statements follow the loop at each level,etc...)

the 'i = -1;' suggested above might have to be followed with a 'continue;' statement (for more than the trivial example given)


------------


You may want to add a retry limiting test if the 'SDL Event' keeps failing at the point that you decide to 'restart' (and possibly cleanup if other context data was setup/allocated/constructed inside the loop -- to bring the data state back to the same it was before the first loop was run)

Share this post


Link to post
Share on other sites

Hi. One thing i can't figure out is how to restart(not break) a loop while i'm in the middle of it. This is just a solution to one of my problems because i couldn't get 2 SDL events working in my main loop. Note the i cant just do a while loop aroudn the whole thing because i only need to separate parts of the code with a restart.
thanks for reading.


try


void common_code()
while()
{
for(...)
{
common_code()
unique_code()
}
for(...)
{
common_code()
}
}

or any other nested loop.

Don't use GOTOs.

Share this post


Link to post
Share on other sites
Also doable with a while loop.


int indexCounter= 0;
while(indexCounter < maxIndex)
{
//SomeCode

if(exitConditionMet)
break;

++indexCounter ;
if(restartConditionMet)
indexCounter = 0;
}


It's pretty much the same as a for loop converted to a while loop, but I know that I find it more readable. Probably not the case for everybody, but for some reason when for loops have their loop counters messed with I always find the code to be harder to understand than if I turn it into a while loop. Just easier for me to grasp more quickly when I'm reading code.

This is probably in part because most people give nondescript variable names to their for loop counters ('i','j','k'...)

Share this post


Link to post
Share on other sites

Hi. One thing i can't figure out is how to restart(not break) a loop while i'm in the middle of it. This is just a solution to one of my problems because i couldn't get 2 SDL events working in my main loop. Note the i cant just do a while loop aroudn the whole thing because i only need to separate parts of the code with a restart.
thanks for reading.


What does your loop look like now ?

Something like ....

for (int i=0;i<whatever;++i) {
firstPartofLoop;
if(someCondition) {
continue; //continue skips the rest of the loop and starts again from the top, if you want to start over completely you have to set i to -1 before continue (the increment will be done afterwards pushing it to 0)
}
restofLoop;
}


should work, (Allthough in my example you could just as easily use else for the second part of the loop)

Share this post


Link to post
Share on other sites

This is extremely clunky and in my entire life I have never needed to use this.
There is always a better way, and you should be looking at why you need to use this type of hack to fix whatever problem you are having.


This can't be emphasised enough. 99 times out of 100, if you ever find yourself needing some kind of evil construct that's not well supported, the possibility is that you're either missing a more obvious/simple way of handling it, or you're trying to threat a symptom rather than the underlying problem itself.

Share this post


Link to post
Share on other sites

I would probably do it with a GOTO statement with a nice clear label like 'goto RESTART_HERE;' (and the label RESTART_HERE: above the FOR statement of course)
which cant be any less obscure/mystifying to what its doing than most other ways of coding it.

And since the whole context inside the loop is probably blown (OP asking to restart the loop without any other qualifying specification)
then the cries of 'it will screw up the compilers optimization for the statement blocks' likely wont be true in this case.



Oh and depending on whats inside the loop (like lots of nesting fun) and how entangled the restart logic case is then multiloop exiting logic
can get very very ugly and complicating the coding for the 'goto-less' solutions (flag testing on every nested loop, exit coding if statements follow the loop at each level,etc...)

the 'i = -1;' suggested above might have to be followed with a 'continue;' statement (for more than the trivial example given)




------------


You may want to add a retry limiting test if the 'SDL Event' keeps failing at the point that you decide to 'restart' (and possibly cleanup if other context data was setup/allocated/constructed inside the loop -- to bring the data state back to the same it was before the first loop was run)


Ok... someone smack this guy! :)

When I read the thread title I was sure I was going to see at least once suggestion to use a goto and I was not disappointed!

If I read the OP correctly, what you want to do is short circuit the loop process right? As in if X condition occurs, stop executing and go to the next iteration of the loop? If that is the case Simon's suggestion is bang on, as that is exactly what "continue" does. That said, when making a post like this, it helps greatly if you include the language you are working in, although I don't know if a language with SDL bindings doesn't implement the continue key word.

Share this post


Link to post
Share on other sites
..stay away from goto statements. Ive never had to use it, ever. It enforces the idea or the disease of spaghetti code to the programmers mind in my opinion.


If you've done your homework, you should already know how to restart the loop hundreds of different ways.
Its also bad to respond to a question like this with code. That teaches nothing but the will to ask more questions later on possibly about the same thing. Learn it, get it out of the way so you can do the same, possibly in a more complex way later. With never having to ask a question about it, in turn wasting your own time.

http://cplusplus.com/doc/tutorial/ Using creativity, you can answer your question yourself

I also teach it online, id be happy to spread my programming religion ;)

Share this post


Link to post
Share on other sites
I'd disagree on the use of goto - absolute prohibitions are usually bogus as all code that could possibly be written obvious has not, and never will be, written, and cases can exist where using a goto can make the programmer's intention clearer. For sure don't use it as a general replacement for other flow control statements, but otherwise it's just another tool in your box. If you find yourself needing to write a tangled mess using regular flow control statements it's clearly a case for refactoring, and if that refactoring involves using a goto - so be it. (It's also handy for exception handling and cleanup in languages that don't have structured exceptions, like C. )

But all of this was covered in another thread some months ago.

Share this post


Link to post
Share on other sites

I'd disagree on the use of goto - absolute prohibitions are usually bogus as all code that could possibly be written obvious has not, and never will be, written, and cases can exist where using a goto can make the programmer's intention clearer. For sure don't use it as a general replacement for other flow control statements, but otherwise it's just another tool in your box. If you find yourself needing to write a tangled mess using regular flow control statements it's clearly a case for refactoring, and if that refactoring involves using a goto - so be it. (It's also handy for exception handling and cleanup in languages that don't have structured exceptions, like C. )

But all of this was covered in another thread some months ago.


Let's put it this way, all of those cases ( which can be argued either way ad nauseum ), those edge cases are so far beyond the beginners forum as to not make sense even considering. Simply put, in a beginners forum , the axiom "never use goto" should simply be consider fact until the reader has the capacity to prove otherwise.

Share this post


Link to post
Share on other sites

Let's put it this way, all of those cases ( which can be argued either way ad nauseum ), those edge cases are so far beyond the beginners forum as to not make sense even considering. Simply put, in a beginners forum , the axiom "never use goto" should simply be consider fact until the reader has the capacity to prove otherwise.


I disagree. If a reasonable solution calls for the use of "goto", or perhaps something similarly dangerous but less polarizing, like fall-through behavior in switch statements, then we should share it and perform our due diligence of saying "Here's a case where 'goto' might make sense because the scope is limited and because it expresses the solution clearly and directly. But don't assume 'goto' is always the answer because ..." While I agree that gotos are dangerous in abundance, I'm not particularly convinced that they are quite so evil individually -- They're kind of like zombies in that way: overwhelming in large numbers, but usually not a problem 1-on-1.

Basically, what I don't agree with is deciding to hide all the hammers just because some shop-class flunkies are bound to smash their fingers once or twice. In other arenas, when you deny that things exist for no reason other than "its in your best interest", we would call that censorship, or at the very least, "spin". Neither has a place in academics. Its more than fine to debate the value of goto, or to advocate fervently against it, but its another thing entirely to deny it to an entire class of people because of their perceived limitations. Have more faith in your fellow man, or at least uphold his innate right to make stupid, uninformed decisions biggrin.gif

That said, more structured solutions are preferable when they are equally clear in their intent, I'm just not convinced that nesting a 'for' loop or two inside of a 'while' loop is more clear in its intention than "goto LOOP_RESTART;" I've had little use for 'goto' myself in C, and less so in C++, but I have had use for it, on occasion.


To the OP: If you want to restart the loop, retaining the current counter value, that is what the 'continue' keyword is for -- don't feel dumb for missing this, 'continue' is not very well known to most beginning programmers, or even intermediate ones. If you want to restart the loop entirely, with a fresh counter, then using 'goto' is one legitimate option. Another is to use a 'break;' statement in the same location you would place your 'goto' and wrapping the for loop in another loop. Which is best is a matter of situation and preference, but both are valid solutions. In any case, be mindful of any other state accessed in the for loop which might need to be re-initialized.

Also, if you have the misfortune of using Visual C++ 6, I'm terribly, terribly sorry. Anyhow, VC++6 is broken, and doesn't respect the scope of for loop indexes like it should -- that is, the scope is not limited to the for loop itself, but to the enclosing scope -- if you break out, or goto a line before the for loop, the value of the variable will likely remain the same as it was when you got out of the loop, and it will need to be reset. Better still, upgrade your compiler to any number of better, completely free (as in beer and/or speech) compilers, including Microsoft's latest Express editions.

Share this post


Link to post
Share on other sites

Basically, what I don't agree with is deciding to hide all the hammers just because some shop-class flunkies are bound to smash their fingers once or twice.


I'd attribute it more to the more specialized types of saws and cutters, which most people, even skilled people, aren't allowed to do until they've used the more basic/common tools because too many people cut their fingers off.

There's no need to give beginners every tool when they can use the tools they have. Over time as finding the best tool for the job becomes important then show them the right tool. I certainly wouldn't advise someone who doesn't know how to creatively use loops to start using gotos.

Share this post


Link to post
Share on other sites

Basically, what I don't agree with is deciding to hide all the hammers just because some shop-class flunkies are bound to smash their fingers once or twice.


I think a more apt analogy would be if that hammer was a occasionally useful hammer, but it had a tendency to give the users slivers. Since there are an abundance of perfectly usable hammers, that particular hammer gets put away.


In other arenas, when you deny that things exist for no reason other than "its in your best interest", we would call that censorship, or at the very least, "spin".
[/quote]

This happens all the time in education. Early history classes don't go into the story of Auschwitz or other catastrophic events in history until the student is mature enough to handle it. Selective education is a very establish and reasonable policy.


Neither has a place in academics. Its more than fine to debate the value of goto, or to advocate fervently against it, but its another thing entirely to deny it to an entire class of people because of their perceived limitations. Have more faith in your fellow man, or at least uphold his innate right to make stupid, uninformed decisions biggrin.gif
[/quote]

Goto is much like the Singleton pattern, an easy crutch early in development, that has a whole lot of downsides that the student is currently incapable of understanding. Like the Singleton, there are *some* cases where it might be a valid construct, but they are a ways down the road.


For someone just getting started with programming, there are already so many things to learn you have to be careful not to overwhelm them. When it comes to streamlining what concepts to introduce and not to introduce, goto should be one of the first items on the chopping block.

Share this post


Link to post
Share on other sites

[quote name='Ravyne' timestamp='1320275860' post='4879922']
Basically, what I don't agree with is deciding to hide all the hammers just because some shop-class flunkies are bound to smash their fingers once or twice.


I'd attribute it more to the more specialized types of saws and cutters, which most people, even skilled people, are allowed to do until they've used the more basic/common tools because too many people cut their fingers off.

There's no need to give beginners every tool when they can use the tools they have. Over time as finding the best tool for the job becomes important then show them the right tool. I certainly wouldn't advise someone who doesn't know how to creatively use loops to start using gotos.
[/quote]

Damn it, your analogy is better than mine. :(

Share this post


Link to post
Share on other sites
[font="arial, verdana, tahoma, sans-serif"]

[quote name='Ravyne' timestamp='1320275860' post='4879922']
Basically, what I don't agree with is deciding to hide all the hammers just because some shop-class flunkies are bound to smash their fingers once or twice.


I'd attribute it more to the more specialized types of saws and cutters, which most people, even skilled people, aren't allowed to do until they've used the more basic/common tools because too many people cut their fingers off.

There's no need to give beginners every tool when they can use the tools they have. Over time as finding the best tool for the job becomes important then show them the right tool. I certainly wouldn't advise someone who doesn't know how to creatively use loops to start using gotos.[/font]
[font="arial, verdana, tahoma, sans-serif"][/quote][/font]
[font="arial, verdana, tahoma, sans-serif"] [/font][font="arial, verdana, tahoma, sans-serif"]
But that's not what's happening here, most of all because fingers don't grow back, but crappy code can be fixed up good as new with a little effort, if and when it proves to be a problem. That's not carte blanch to write shitty code just for kicks and laziness, I'm just pointing out that sometimes a single goto is the elegant solution, as opposed to erecting some otherwise useless super-structure, and we shouldn't pretend that that isn't the case because we don't think a beginner can handle the truth. Besides, lets not pretend that someone who would be naive enough to abuse goto is writing mission-critical software. Most likely that code will be buried in some text-based tic-tac-toe program that will never leave the comfort of their hard-disk, and then disappear in a disk-crash because it wasn't worth backing up.[/font]
[font="arial, verdana, tahoma, sans-serif"] [/font]
[font="arial, verdana, tahoma, sans-serif"]Also, what's essentially been advocated above by many, is to make the solution more complicated than it needs to be, in order to feel good about the way it got solved. That's almost always terrible advice (note that this is not the same thing as "do the simplest thing, regardless of where the code is heading."). That's precisely the line of reasoning that makes Singleton attractive -- It's global state that *feels" all happy and object-oriented -- a wolf in sheep's clothing.[/font]


[quote name='Ravyne' timestamp='1320275860' post='4879922']
Basically, what I don't agree with is deciding to hide all the hammers just because some shop-class flunkies are bound to smash their fingers once or twice.


I think a more apt analogy would be if that hammer was a occasionally useful hammer, but it had a tendency to give the users slivers. Since there are an abundance of perfectly usable hammers, that particular hammer gets put away.
[/quote]

Fine, but we don't pretend that this thorny hammer doesn't exist -- we say "Go get the Thorny Hammer, but put on some freaking gloves, will you!" -- If we leave out the part about wearing gloves, then it is we who have failed, rather than the dude swinging the thing.


In other arenas, when you deny that things exist for no reason other than "its in your best interest", we would call that censorship, or at the very least, "spin".
[/quote]

This happens all the time in education. Early history classes don't go into the story of Auschwitz or other catastrophic events in history until the student is mature enough to handle it. Selective education is a very establish and reasonable policy.
[/quote]

But it cuts both ways -- sometimes you have to introduce a topic ahead of where it can be fully explained in order to progress -- and in that case you tell the receiver of the information what they need to know, with due caution and without premature bias.

Take for example the mathematical identities: (-1)^(2n) = 1 and (-1)^(2n - 1) = -1 [where n is an integer]

These identities (particularly replacing -1 for any negative integer, and the result with a positive and negative unknown, respectively) is common in high-school level algebra and calculus, but a mathematical proof of this concept is well beyond a high-school classroom -- yet, students must know this identity in order to be presented with many interesting problems.

As much as I am for knowing how things work internally, its not always practical to simply say "You cannot prove it is, so therefore you cannot use it" -- indeed, sometimes this is antithetical to progress.


Neither has a place in academics. Its more than fine to debate the value of goto, or to advocate fervently against it, but its another thing entirely to deny it to an entire class of people because of their perceived limitations. Have more faith in your fellow man, or at least uphold his innate right to make stupid, uninformed decisions biggrin.gif
[/quote]

Goto is much like the Singleton pattern, an easy crutch early in development, that has a whole lot of downsides that the student is currently incapable of understanding. Like the Singleton, there are *some* cases where it might be a valid construct, but they are a ways down the road.[/quote]

Singleton is very different and much more insidious -- just *one* Singleton make predicting program state impossible (at least at the level of mathematical proof) and has global reach by definition. Goto can, and should, be limited in scope -- to a single, local scope in 99 cases out of 100; neither should a goto break down in the face of multi-threaded programming in the way that naive singleton implementations do. Singleton is essentially *never* a necessary construct unless there are devices or assumptions it represents that exist in the physical world -- eg, a resource in an integrated circuit that is by definition (rather than convenience) singular.

I'm certainly not advocating that goto is a good thing, or that one should jump across function or module boundaries with one -- I'm merely saying that in a certain set of circumstances, with limited scope, and clear intentions, a goto can be a good solution -- and that to pretend otherwise, no matter how badly it falls apart at large scale, is intellectually dishonest and unpragmatic, particularly when alternative solutions are needlessly complicated.

For someone just getting started with programming, there are already so many things to learn you have to be careful not to overwhelm them. When it comes to streamlining what concepts to introduce and not to introduce, goto should be one of the first items on the chopping block.
[/quote]

I agree with the premise, but not the conclusion. The way to not overwhelm someone is not to tear out parts of the map, but to mark the dangerous parts of the world with a big red X, and where a clear and pragmatic set of rules exist for negotiating this dangerous territory, to share them.

Back in the day, when many newbie programmers cut their teeth on assembly language, all they had were essentially gotos -- yet, no one said "Dear God! Run! That JMP statement is about to bite!" people understood the purpose and ramifications of the various jump statements. Perhaps it can be said that structured languages make it easy, or even attractive to jump willy-nilly through great expanses of a program, but the mechanism itself is no more or less dangerous than it was back then. Indeed, if structural programming, where it has not *completely* alleviated the need for goto, does indeed serve to obfuscate the potential negative consequences of using it, then our reaction should not be to place it behind glass and chide new programmers never to touch it, but to re-double our efforts to explain *why* it mostly sits high on a shelf, behind glass these days -- After all, the tool which is most dangerous to you is the one you know nothing about.

Share this post


Link to post
Share on other sites
I'd actually say that goto is much cleaner and less prone to WTFery than some creative uses of loops you sometimes find: witness Duff's Device (although goto is not a replacement there, but it is an example of a creative loop) or the do [...} while (0) pattern. A certain school of argument is that break and continue are nothing more than specialized forms of goto anyway. It's certainly no harm having beginners be at least aware that goto does exist, and aware of the reasons why it should not be your first choice, otherwise the risk is that they'll discover it on their own elsewhere. For that last reason alone I think that suppressing the information does more harm than good, despite best intentions.

So my analogy is that goto is like sex education. They're going to find out anyway, and if they find out from the wrong sources they're going to end up with a jumble of confusing and incorrect information and may end up trying out things that they really shouldn't. Better they find out the right way. ;)

Share this post


Link to post
Share on other sites

So my analogy is that goto is like sex education. They're going to find out anyway, and if they find out from the wrong sources they're going to end up with a jumble of confusing and incorrect information and may end up trying out things that they really shouldn't. Better they find out the right way. ;)


Good sir, you win the Golden Analogy Award. Congratulations!

Share this post


Link to post
Share on other sites

[font="arial, verdana, tahoma, sans-serif"] [/font][font="arial, verdana, tahoma, sans-serif"]But that's not what's happening here, most of all because fingers don't grow back, but crappy code can be fixed up just fine with a little effort,
[/font]
I'm not 100% sure I agree with that. I've had to rewrite a lot of things from scratch because "as long as it works" fixes were put in. It's a huge waste of time when all that needed to be done was to step back and look at the desired functionality and design it properly.

Obviously in the working world there's things like deadlines and jazz that complicate that whole bag, but when learning I'd stress solving the design problem over solving the scheduling problem every time :)


I'd actually say that goto is much cleaner and less prone to WTFery than some creative uses of loops you sometimes find:


If you are in a situation where this is needed I feel like there are larger problems that won't be solved by using goto.

Goto is most often replaceable by other structures that are usually better encapsulated (both visually and functionally), often shorter, and are present in almost all languages in popular use.

The problem with teaching Goto to beginners is because it is an easy band aid for design problems but doesn't actually fix the design problem, just the functionality problem.

edit:
[color=#1C2837][size=2]So my analogy is that goto is like sex education. They're going to find out anyway, and if they find out from the wrong sources they're going to end up with a jumble of confusing and incorrect information and may end up trying out things that they really shouldn't. Better they find out the right way. ;)[color=#1C2837][size=2]

[/quote]


[color=#1C2837][size=2]

I'd agree, but they still don't really give sex education until you're a teenager. If you tried to teach sex education to a bunch of 6 year olds you'd do a lot more harm than good even if you were the right source.

[color=#1C2837][size=2]

Share this post


Link to post
Share on other sites
Trivial examples dont really show whats involved with real world code (so nice and clear when all parts of the more complex but 'pure' or 'correct' control pattern
are 3 lines apart, but not quite that clear when there are 5 pages of other code between the different bits obscuring the parts)

I thought the OP was talking about 'restarting the loop' entirely (not just going back up to the top of one iteration)

If a call (SDL) is failing then a local retry loop (definitely with a limit and then a failure exit path) would be called for.
I still might the use another GOTO for the exception path to jump down to a cleanup phase (and again likely bypassing alot of other code and avoiding alot of extra special exit handling logic).

Ive been programming (professionally) for 30 years (has it really been that long) and have read/scanned millions of lines of code and fixed alot of bugs caused by other programmers screwing up their control flows. Its much easier to interpret/debug the code when its shorter/simpler/clearer (ie- comments do help and also goto LABELS that mean something).
So many NON-trivial cases where complexities (shear length, multitudes of nestings/logic paths, etc..) turned the 'pure' structured programming into a horrendous mess.

The hatred for the noble 'goto' statement probably originated back in the old Fortran days when gotos only jumped to line/label Numbers and comments were minimalized (and those Fortrans often could only do single THEN statement -- very often a goto jump). An absolutism developed due to the pain of those restrictions leading to academics preaching their goto-less ideology frequently with little experience of the real world complexity of many programs. They attempted to banish something so simple when their designs very often required 'three lefts to make a right' instead.


Anyway, Ive used more than a few gotos -- most usually for exception processing and some more to eliminate alot of ugly deep exiting/retry logics, always using
clear labels and good comments explaining the divergence of the control flow. I use Breaks and Continues when they are simpler (again with comments since they are often not obvious of themselves where the control transfers to.

I vaguely recall that someone proposed C/C++ having Continue/Breaks to be able to specify which (named) nested loop/block they processed (ie- breaking out/jumping several loop nestings) which could eliminate/cleanup many common exit coding situations.

Share this post


Link to post
Share on other sites
Meh. I have yet to use a goto statement in my code, but to be honest I'd rather see someone use a goto statement rather than a do { } while (0) with continues/breaks. But even more so, I'd rather see someone just wrap the bloody thing in a function and use an early return than a goto statement or a do { } while (0) with continues/breaks.

My opinion is just to make everything as atomic, short, simple, and clear as possible. Don't sacrifice common sense for fear of using a tool of the language, but also don't abuse any tool of the language either. This involves gotos and everything else there is. No sense in starting a holy war.

But yeah, I'd say to the beginner learn what a goto is, and then try to never use it (I didn't say never use it; just try not to). If your code is riddled with gotos you're probably doing it wrong.

Share this post


Link to post
Share on other sites
All this talk of whether to GOTO or not is quite theoretical. Unless the OP shows us the source we can't really divine which would be the messier solution.

That said, I rarely think of "restarting" a loop when I'm coding, so I'm guessing the OP has maybe an atypical algorithm, or is handling errors in an unusual manner. My gut reaction is that using a goto will probably make the situation worse. To add my own terrible metaphor to the mix, gotos are like intense radiation. You should avoid exposure in general, but it can occasionally be useful for killing off cancerous growths (i.e. spaghetti code).

I'd like to see the OP's code, because "i couldn't get 2 SDL events working in my main loop" doesn't sound like something that should be a problem, and the "solution" of "restarting" a loop is suspicious.

Share this post


Link to post
Share on other sites
I have yet to find a use for goto that I was satisfied with. Anywhere.

Regardless, it's not even clear what the OP means by "restart".

Share this post


Link to post
Share on other sites

All this talk of whether to GOTO or not is quite theoretical. Unless the OP shows us the source we can't really divine which would be the messier solution.

That said, I rarely think of "restarting" a loop when I'm coding, so I'm guessing the OP has maybe an atypical algorithm, or is handling errors in an unusual manner. My gut reaction is that using a goto will probably make the situation worse. To add my own terrible metaphor to the mix, gotos are like intense radiation. You should avoid exposure in general, but it can occasionally be useful for killing off cancerous growths (i.e. spaghetti code).

I'd like to see the OP's code, because "i couldn't get 2 SDL events working in my main loop" doesn't sound like something that should be a problem, and the "solution" of "restarting" a loop is suspicious.


This.

This whole question really smells like a bowl full of fish guts (since we're making outlandish analogies :) ). I'd really like to know what the OP is actually trying to do, since it sounds like he/she is trying to band-aid some kind of massive, leaking head wound.

Share this post


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

  • Advertisement