|
Now I'm going to have to visit that place.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
You tell me
»»» <small>Loading Signature</small> «««
· · · <small>Please Wait</small> · · ·
|
|
|
|
|
Certainly not the conference.
Not one of the presentations is about the goto .
They should be done for false advertising.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
|
I believe you'll find that all those accounts written hundreds of years after the alleged events were entirely factual...
|
|
|
|
|
Not true: in some machines it's called a JUMP instruction instead!
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
Ah, but if you look at the compiled machine code, it's exactly the same, so JUMP is just another abstraction of goto .
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Mark_Wallace wrote: when you compile your code, every transition from one statement to another is translated into a goto .
Assuming that the "another" statement is not the one immediately following.
|
|
|
|
|
Why? Using a goto to exit a loop is one its few (perhaps only) valid use cases.
/ravi
|
|
|
|
|
I've been known to use it for "load variable amounts of stuff from DB as needed" and use goto to get to the cleanup/UI enabling at the end. It probably comes from the habit of preferring:
void someFunc()
{
if (!A)
return;
DoStuffWithA()
DoMoreCrud();
}
rather than
void someFunc()
{
if (A)
{
DoStuffWithA();
DoMoreCrud();
}
}
|
|
|
|
|
Was your reply meant for another post?
My name is not Shirley. Sure, my post was about flow control, and could compile into goto (/jump) instructions, they are certainly not The Answer in this case.
|
|
|
|
|
An elegant solution, Shirley!
Will Rogers never met me.
|
|
|
|
|
Why, thank you, Shirley.
They say that elegance is simplicity, so I must be pretty elegant.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Goto the cockpit and see what the hold up is.
And don't call me Shirley.
|
|
|
|
|
What about this?
foreach (x in someContainer)
{
ret = someFunction(x);
}
int someFunction(whatever x)
{
if (someCondition) return 1;
if (someOtherCondition) return 2;
return 3;
}
Is this close to what you meant, or did I miss the point?
|
|
|
|
|
Still you must analyze those "ret" values, and values 1, 2, 3 do not syntactically convey the information that you reached the end of the collection (or skipped out of the loop). You need this extra "ret" value, which must be declared for this one-time use. While your proposal might be a starting point for explicitly coding what the compiler might generate, it certainly does not have the readability and syntactical clearness that the exitfor/exitwhile syntax has.
Also, I doubt that the compiler would code it as a function. It would generate one jump label for the exitwhile clause, another for the exitfor (both defaulting to the first statement following the loop). The top line iteration test would jump to the exitfor label when the looping condition fails, the while statements would jump to the exitwhile label when it fails.
If the language would provide block local program labels, visible only within the loop, I could code my example as
for listpointer = listhead:nextfield do
...
if listpointer.keyvalue = desired_key goto exitwhilelabel
...
if listpointer.nextfield = null goto exitforlabel
exitwhilelabel:
... object found
goto endforlabel
exitforlabel:
... object not found
goto endforlabel
endforlabel:
endfor
This is what a reaonable compiler would generate - but I think it ugly when written out in longhand code. Besides, jump labels do not have block local scope in any language I know of, so you would have to invent new labels for every loop using this mechanism ("if listpointer.keyvalue = desired_key goto exitwhilelabel117" - even more ugly!)
I tried to make C macros that would generate unique labels, but the problem was to make the asocciation between the while part (or if test in the code above) and the appropriate exitwhile. A compiler could easily do this.
(Tne "goto endforlabel" in the exitfor clause is redundant and would be optimized away, but it allows the exitfor and exitwhile clauses to be switched around.)
|
|
|
|
|
I'd suggest an enum over magic numbers.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
I like that ... for that matter, why loop at all? Just use goto and loose the while/for - just wear some flame retardant apparel.
Actually, hang on, why even use goto? Why not copy-paste the code the required number of times instead of looping at all! Yeah! That's what Id do!
|
|
|
|
|
I haven't read all the responses that may or may not give a hint in that direction, but what exactly is it that these commands do that a break statement in C doesn't?
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
Here is a real world example for you
for (property = 0, len = obj.length; property < len; property++) {
if (callback.call(obj[property], property, obj[property]) === false) {
break;
}
}
Once the following is true (callback.call(obj[property], property, obj[property]) === false), there is no point in continuing the loop, as a result the break will exit the loop.
If the method has the answer it is looking for, you can also do
for (property = 0, len = obj.length; property < len; property++) {
if (callback.call(obj[property], property, obj[property]) === false) {
return 1;
}
}
so that not only will the loop end, but if there is nothing more in the method which will add value to the answer, the data is returned without needing to continue (bad choice of words, since continue has it's own special meaning) the loop and without needing to look at any more code.
|
|
|
|
|
That wasn't my question at all. I know what break does. And exactly because I understand what it does, I do not understand the original question!
I don't know Planc, but from the original posting my understanding was that the commands pointed out there - exitfor, exitwhile - simply exit from the loop. Just like break does. I don't see the difference, and therefore I don't see the point of the question.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
After a loop, how do you know if you finished it or breaked out of it?
This post is not about just leaving a loop, but about knowing how you left it and act according it.
We probably all know how to do that in c, but this is about a language that adds syntax elements for that.
|
|
|
|
|
Looks like a nonsense reason, to me. You can just put a message before the break statement.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Mark_Wallace wrote: You can just put a message before the break statement. Goto! Before the goto statement!
Damn!
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
How do you know the difference in Planc if you used exit*** ?
As I said, I don't understand what, exactly, these statements do, and the OP doesn't inidicate they do anything beyond breaking out of the loop. That's what break does, too. Hence my question.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|