macOS Obj-C: breaking out of loops and conditionals

[GregX999]

I have a pretty basic (I think) question. If I have a set of nested loops and/or conditionals, for example like this:

for (Hex *h in potentialNextHexes) {
	hexIntersect = [self hex:h IntersectsLineFrom:hOrigin to:hTarget];
	if ([self distanceBetweenHex:h andHex:hTarget] <= distance && hexIntersect > HEX_WAS_MISSED) {
		if (hexIntersect == HEX_WAS_CROSSED) {
			*next1 = h;
			STOP THE LOOP!!!
		}
		if (*next1 == nil) *next1 = h;
		else *next2 = h;
	}
}

What command can I replace "STOP THE LOOP!!!" with that will break out of the two if statements and the for loop? (I don't want the for-loop to continue no matter how many "potentialHexes" may be left to still iterate through.)

Thanks,
Greg

 

[Eraserhead]

break;

Like any other C based language .

 

[GregX999]

Oh, I thought that would just break out of the if block. I see now that it only breaks out of loops.

Obj-C is my first encounter with a C based language.

Thanks!
Greg

 

[jared_kipe]

Often time, when you want to get out of a nested loop you are done with whatever method or fuction you were trying to do (you can probably always make this the case by creating a function/method to do whatever the nested loop is doing).

Hence, you could just use
return; // and return whatever it is you want if you need to.

 

[Cromulent]

Another option is to use goto to break out of deep nested loops. One of the few situations where goto seems to be accepted.

 

[jared_kipe]

Another option is to use goto to break out of deep nested loops. One of the few situations where goto seems to be accepted.

I have heard goto has become highly frowned upon.

 

[Eraserhead]

Obj-C is my first encounter with a C based language.

For its worth C based languages do include Java, Javascript and C# as well as C, C++ and objective C .

By this I mean that if you know how to do something in Java, C# (especially) or Javascript it'll probably be the same in C.

 

[Cromulent]

I have heard goto has become highly frowned upon.

Not when used in the way I suggested.

Goto is not bad in itself, it is just bad when used for silly reasons.

 

[iSee]

Though goto isn't always used in a bad way, it might be that there is always a better alternative. If you are considering goto first consider other options.

jared_kipe's refactor is a good, general purpose alternative, for example, because when goto is used to implement flow-control operations it should never jump past the boundary of a single logical operation at any particular level -- actually a goto should only jump to the boundary of a logical operation. In the refactor that jared_kipe suggests, the boundaries of the logical operation are defined by the function, which is nice and good for a bunch of reasons.

goto is also legitimately used in certain error handling situations. But when this is done in a robust, organized and consistent way it starts to look a lot like exception handling. Why not simply use an exception handling mechanism? (You can very likely find an existing one for your environment so you won't need to implement your own).

 

[Ti_Poussin]

Another option is to use goto to break out of deep nested loops. One of the few situations where goto seems to be accepted.

using GOTO!!! a raptor will come to eat you if you do that (XKCD joke here)!
GOTO is bad programming, you should not use that, except in really rare case, and this is not one.

The function and break are the good solution here. Even a check on a boolean condition could be better then goto but still a bad approach.

Edit: http://xkcd.com/292/
lol

 

[sushi]

^ Agree.

With high level languages, only use a Goto statement as the last resort.

 

[Cromulent]

using GOTO!!! a raptor will come to eat you if you do that (XKCD joke here)!
GOTO is bad programming, you should not use that, except in really rare case, and this is not one.

The only reason using goto statements is considered bad programming is because it can lead to spagetti code. If all you are using it for is jumping out of nested loops then that is not a danger.

It often provides the easiest, quickest and arguably fastest implementation. I certainly agree that it is bad in the majoity of cases but this is not one.

Still I guess it comes down to opinion. I've certainly seen goto statements used a lot in large development efforts (the Linux kernel for instance), so it seems that refusing to use it at all is somewhat limiting.

 

[lee1210]

^ Agree.

With high level languages, only use a Goto statement as the last resort.

And a thorough consideration of what "last resort" means. I'll refactor a whole subroutine if it will save using a goto. This may seem like a waste, but when a bug or need for enhancement crops up in that area later, there's always a net savings.

I ported (from HPUX on PA-RISC to Linux on x86) and now maintain ~25 year old fortran (a lot using pre-77 syntax). Cycle and exit are now available, allowing for reasonable loop execution control, but all of the old code has dozens of labels per file, with gotos at every turn. Following flow control is nearly impossible. This is an extreme case, but just one to avoid a refactor, as Ti_Poissin pointed out, uniformly leads to a raptor attack.

-Lee

 

[kainjow]

A project I'm working on uses goto all the time, and the main dev still uses it in new code, and uses it improperly. Mainly problems with goto-ing a label and using a pointer that may not have been assigned. Fortunately GCC catches those problems.

 

[lee1210]

Still I guess it comes down to opinion. I've certainly seen goto statements used a lot in large development efforts (the Linux kernel for instance), so it seems that refusing to use it at all is somewhat limiting.

Hopefully the folk writing that code know better, and have truly weighed the cost in readability with the performance of doing, say n-2 (where n is nesting depth) conditional branches to test a "done" variable at each level and break, etc. If you're writing code whose speed will truly suffer performance problems in this case, and there is no way around it, it would be fool-hardy to ignore the possibility of a goto. It should pain you, and you should have your raptor-gun ready, but it may be a compromise that has to be made. I have never run into a situation where a goto would need to be considered for performance reasons, but i'm sure the need does arise.

iSee pointed out exception handling, and for performance reasons (at least as I understand it) C++ has been rejected for use in the Linux kernel, which would be the shortest path to exception handling.

We're at well over a dozen posts, we've sort of beat this to death. The OP is new to programming, at least C-style syntax, so they're probably unlikely to be running into any situation where a goto is truly the only option. Imploring them against using it and instilling the fear of God/Raptor in them at this point is probably in everyone's best interest, in case the OP is going to post code snippets that we want to read here later, etc.

-Lee