next topic »

[on:]

At last we can use GOTO again without being vilified

The new MISRA standard now allows it's use (with caveats), I haven't seen the standard yet but here's a excerpt from an article on the Electronic Design site (http://electronicdesign.com/dev-tools/misra-c2012-plenty-good-reasons-change?NL=ED-07&Issue=ED-07_20130226_ED-07_678&YM_RID=rob@robgray.com&YM_MID=1375780&sfvc4enews=42)

Not All Goto Statements Patch Up Wooly Thinking!

All too often, goto statements are used to patch up wooly thinking or an ill-defined algorithm. However, there are situations where the use of the goto statement is justified. For example, if there is an emergency situation in a process-control application, is it really better to set a flag and check it later in the algorithm than to take a direct route via a goto?  The “goto statement should not be used” rule is now advisory rather than required, and an additional two rules narrow down the circumstances under which it is acceptable:

    The goto statement shall jump to a label declared later in the same function.
    Any label referenced by a goto statement shall be declared in the same block, or in any block enclosing the goto statement.

So all us wooly thinkers are off the hook now

______
Rob

[Reply #1 on:]

Nooooooooooo, yee shall not pass goto, for if thou do'eth thou surely be cast into thee depths of eternity, lost and abandoned it time, never to return.

[Reply #2 on:]

    The goto statement shall jump to a label declared later in the same function.

So, you can't use it for loops.

[Reply #3 on:]

Yeah, it looks like you can only jump forward.

Rockwallaby, I'll have what you're having

______
Rob

[Reply #4 on:]

in case of an emergency you can use goto but you must not expect the system in a defined state thereafter. Even a graceful degradation is doubtful at best.

If you detect a real emergency (the "Houston we got a problem" kind) why not call the emergencyHandler() ?
And return afterwards and continue?

[Reply #5 on:]

If you detect a real emergency...

... who you gonna call? ghostBusters()

But if you have a huuuuge @#$%up, call Todd() ....

[Reply #6 on:]

LOL !

[Reply #7 on:]

GOTO "never left the building" for assembly language programmers.

[Reply #8 on:]

If you use GOTO, I think you are going to end up calling Todd (see graphic above).

[Reply #9 on:]

Will spaghetti be served again? 

[Reply #10 on:]

call Todd

I saw that sign recently on one of those "funny photos" sites, under the heading "Meanwhile in Aus" or some such. It's a classic.

______
Rob

[Reply #11 on:]

GOTO "never left the building" for assembly language programmers.

+1. Goto, Jump, Branch...

[Reply #12 on:]

I saw that sign recently on one of those "funny photos" sites, under the heading "Meanwhile in Aus" or some such.

Well you guys do have a certain "way" with words, let's face it...

[Reply #13 on:]

I involved myself in this conversation way-back-when on the electro-tech forum, regarding state machines:

http://www.electro-tech-online.com/general-electronics-chat/113718-state-machine-mcu.html

In it, me and another user (MikeMI) have a discussion regarding state machines and whether using IF-THEN logic and GOTOs for such implementations (vs a switch-case construct) is better, worse, or...?

Anyhow - he posted an image of an implementation of such a state machine:

http://www.electro-tech-online.com/attachments/general-electronics-chat/48665d1291323569-state-machine-mcu-elevator.png

(you'll need a login to see it) - or check it out here, rehosted: http://i.imgur.com/JkND1Av.png

Anyhow - I found that example of using IF-THEN logic and GOTO to implement such logic to be very interesting; it wasn't difficult to follow, and made me appreciate GOTO a bit more (I grew up on Microsoft BASIC on a TRS-80 Color Computer - GOTO was in my blood for a long time, until it was excised during my first professional software development gig).

I now think of it as one of those tools that one should be aware of, but should only use when the situation absolutely warrants it - breaking out of deeply nested logic is one potential area (provided you don't break a stack or something); though I would perhaps do some investigation into that logic to see if maybe there is some way to make it more workable without requiring such a sledgehammer measure.

...and a second potential situation would be this example of a state machine.

I have also seen an instance (when I worked at a place that used a variant of COBOL called DB/C) where GOTO was used to jump out of (or into? it's been so long now) an error "trap" routine; but the developers there who worked in that system (I was only peripherally involved) made it explicit that such use was the -only- place that GOTO was allowed in the software they developed, and no where else.

[Reply #14 on:]

I now think of it as one of those tools that one should be aware of, but should only use when the situation absolutely warrants it

Like using water-pump-pliers to undo a nut....