next topic »

[Reply #15 on:]

mem;

 I understand and respect your point. It's just I would think doing "what's best for someone" can at some point be seen somewhat condencending at times. The extended reference ( http://arduino.cc/en/Reference/Goto ) has a good definition and example of using GOTO and even discusses the merits and pitfalls of using it as we have been discussing here for the OP.

So it's in the C language, it's in the Arduino reference, but for begineers we should treat it like the crazy aunt we keep in the basement and not mention her?  

Lefty

[Reply #16 on:]

It isn't condescending to advise newcomers to avoid techniques that are potentially troublesome (whether they are in the reference material or not).

I may be beating this point to death, but would you agree that its not helpful to the novice programmer struggling to learn how to use functions in a simple sketch, to see expert opinions on using goto in structured exception handling.

A good part of the appeal of Arduino is that it hides all that ugly stuff we engineers love to wrestle with.

[Reply #17 on:]

Sure, you never *have* to use goto and you will always be able to find a way around it. But I would argue that in this case (pseudo exception handling), the single-function top-to-bottom approach with goto is easier to read. No passing buf back and forth, no return codes to remember (and get wrong), etc.

I wouldn't call it pseudo exception handling, it's not that robust and still vulnerable to deeper errors, it's just a wrapper function.

In this short example, there isn't much difference, but as you add more things to be done within the code then the goto example would become increasingly more difficult to follow.  In either example you need to remember the error codes.

Another thing to remember it's not just how you look at the code, but that other people might have to (or yourself months later). When you use a goto, the reader has to jump through the labels to get an understanding of what a function really does. By putting essential elements into functions (and naming them appropriately) it's much easier to look at the code and determine quickly what it does.

[Reply #18 on:]

I wonder if the discussion about the  use of goto for structured exception handling is out of place in a thread on Arduino syntax.  

This thread is called Whats up with GOTO command?.

I do not think it is out of place to discuss the GOTO. It is a part of c, and thus a part of Arduino.
And, I do think that it has been quite a heavy emphasis on why not to use the GOTO.

Misapplying or abusing a tool is not the fault of the tool nor does it justify throwing the tool away.

I very much agree.

[Reply #19 on:]

GOTO is still around... plain and simple. If it were truly EVIL, it would be gone.

But, how about an analogy...

If you can hammer in a nail with a ROCK you will still get the nail hammered in... but if you had a hammer nearby... why use the ROCK?  Well, human nature... somebody will insist a ROCK is easier.  

There may even be cases where using a GOTO will let you produce LESS code and that can be good for the limited Arduino code space.

The question should not be "What's up with it?" but rather "is it the best choice?" when using it in your code.   It's your code and if it becomes "spaghetti" as a result of GOTO's... you'll be the one untangling the mess in the future.

[Reply #20 on:]

Thanks pwillard I didn't know much about how to use the "hammer" or why the hammer was better than the "rock" but I'm getting the point about functions over GOTO's now.

Quote:
The question should not be "What's up with it?" but rather "is it the best choice?" when using it in your code.
I should have restated the topic to "Is it the best choice" because that was kind of what I was asking, I just phrased it weird sorry  

[Reply #21 on:]

goto == the crazy aunt you don't talk about  8-)

[Reply #22 on:]

goto == the crazy aunt you don't talk about

 ;D  Thats the most succinctly I've ever seen it put.

[Reply #23 on:]

Unconditional jumps are used extensively in C, "break" and "continue" are both unconditional jumps - "goto" is simply an unconditional jump to a label.

goto's implemented over short distances to clear labels are justified when you need to balance speed, minimisation of stack use and minimisation of code size.

The most useful situation I have seen goto's used is in the context of a device driver, when a sequence of resources need to be secured prior to an operation being performed. In the event of an error associated with the allocation of one of the resources, the resources already allocated need to be released in the opposite order to their allocation (it's good practice to do this to avoid deadlock). goto offers a concise solution to this operational paradigm:

Code:

get resource A
if (error)
  goto out_a;
get resource B
if (error)
  goto out_b;
get resource C
if (error)
  goto out_c;
perform actions;
goto out;
out_c:
  undo C
out_b:
  undo B:
out_a:
  undo A
out:
  return ret;

The alternative, using nested if's, looks worse and requires a lot of extra work if you add another resource to allocate, or if you use functions then you use up limited stack space (unless you inline, and then you get code bloat)

Frankly, if you can follow program flow which uses break or continue (which don't have labels), you should be able to follow program flow which uses goto sparingly and clearly. If you can't, then you have no business touching someone else's device driver code.

Overall, I think that the education strategy of goto avoidance is worthwhile, but at some point you ought to become proficient enough to be trusted with all of a language's features, judiciously applied.

[Reply #24 on:]

I think this is better/more concise.
Although slower, I would presume that the speed of performAction is a lot more important the than the preparation for it.

Code:

if (getResourceA() && getResourceB() && getResourceC()){
  performActions();
} else {
  releaseResourceC();
  releaseResourceB();
  releaseResourceA();
}

I do not see 'break' or 'continue' as unconditional jumps. You are aware of exactly what your code will do, and how it effects program flow, if using there keywords.
A goto out_a; might not be as clear, and thus not comparable. (That's ofcource my opinion.)

All this said, I agree with:

Overall, I think that the education strategy of goto avoidance is worthwhile, but at some point you ought to become proficient enough to be trusted with all of a language's features, judiciously applied.

 

[Reply #25 on:]

I have been taking issue with AlphaBeta in this thread, it's a pleasure to find myself in agreement with his post above.

I do feel some comments in this thread miss the point about the community that Arduino was designed for. The artists, designers and hobbyists that are the Arduino target do not need to “become proficient enough to be trusted with all of a language's features”.  
To me, Arduino is about hiding the complexity of the C language so that users more interested in tinkering than software engineering can build cool things.

[Reply #26 on:]

I do feel some comments in this thread miss the point about the community that Arduino was designed for. The artists, designers and hobbyists that are the Arduino target do not need to “become proficient enough to be trusted with all of a language's features”.

grumble, grumble, Well, yeah I guess. That is a very good point.

... So who thinks you should only use CSS, and <tables>'s are EVIL (just kidding)