GOTO is alive and well. Dijkstra, eat my pants

In some languages, you don't have much choice. In a modern, high-level language like Python, I find exceptions work brilliantly for error handling.

--
Grant Edwards                   grante             Yow!  Hello? Enema
                                  at               Bondage? I'm calling
 Click to see the full signature
Reply to
Grant Edwards
Loading thread data ...

Better yet, try it and see.

--
Grant Edwards                   grante             Yow!  Hand me a pair of
                                  at               leather pants and a CASIO
 Click to see the full signature
Reply to
Grant Edwards

Cool, I might look for a copy.

Fair enough -- I probably mis-read something.

Damn. I can't believe I keep mispelling his name.

If the point in question is whether you need gotos for Turing completeness, then of course you're right. EWD's point was more of a real-world common-sense observation than any sort of technical CS claim.

True.

Hang onto those!

--
Grant Edwards                   grante             Yow!  Hmmm... a CRIPPLED
                                  at               ACCOUNTANT with a FALAFEL
 Click to see the full signature
Reply to
Grant Edwards

To paraphrase Kernighan: exceptions are great for exceptional circumstances. If "error handling" qualifies as exceptional circumstances, which is the bit I'm grumbling about, then ok. Otherwise, I'll take your exception and raise you a state machine.

Steve

formatting link
formatting link

Reply to
Steve at fivetrees

We had a conversation at work today about finding the "right" kind of person to add to our firmware development group. We decided that we don't need someone who can program in assembly (I know! I thought it was heresy also, but I'm old.) but we do need someone who knows the value of telling the compiler to produce assembly and can interpret the results.

I hope that understanding the underlying machine never becomes a lost art.

-Rich

--
Richard Pennington
Email: rich@pennware.com
 Click to see the full signature
Reply to
Richard Pennington

And that means they need to know how to program in assembly. ;)

Most embedded work involves a little bit of assembly anyway (e.g. start-up code, interrupt handlers, context switching, IP checksum routines that are taking up too much CPU time, and so on.)

Don't forget to make sure they know how to use the delayed trigger timebase feature on an oscilloscope.

--
Grant Edwards                   grante             Yow!  A dwarf is passing
                                  at               out somewhere in Detroit!
 Click to see the full signature
Reply to
Grant Edwards

Unlike Dijkstra..

Reply to
TheDoc

Yes, but don't tell them that. It's not stylish anymore.

I'd be happy with someone who can add some debug output in the right place. Some of our stuff is rotating on a chassis at 2 rev./second (with about 1000 kg of other stuff) and we have one simple communication path. Not much opportunity for oscilloscope or JTAG connections.

Unfortunately, finding the right place to do the debug output is also fast becoming a lost art.

-Rich

>
--
Richard Pennington
Email: rich@pennware.com
 Click to see the full signature
Reply to
Richard Pennington

I agree with the concept, and generally follow the practice. I have been known to use such constructs as

void Testfunction( int invalue){

if(invalue < MINLIMIT) return;

// 30 lines of actual work if invalue is in limits

}

as opposed to:

void Testfunction( int invalue){

if(invalue >= MINLIMIT) {

// 30 lines of actual work if invalue is in limits

} }

Since the second construct, while preserving the single-exit principle, may put the end of the conditional code off the bottom of the page. In addition, putting the 'return' in a few place may greatly enhance the readability of a complex set of nested logical tests.

I suppose that you could get the same effect with a 'goto exitblock' statement, though.

I know you can do this in assembler----and have even seen it used in wierd ways to conserve a few bytes of code. But is multiple-entry doable in C??

Mark Borgerson

Reply to
Mark Borgerson

Bah humbug - this entire thread is off-topic. But irresistible ;).

The continued use of GOTO baffles me. State machines (yeah, I know, I'm repeating myself) solve all these problems and more. Properly coded, there's no efficiency loss - far from it, they're usually way faster (and a squillion times more maintainable) than a purely sequence-and-panic approach.

Makes good sense. But I share your pain ;).

I've occasionally *been* the compiler (i.e. I've designed in C, and then coded in assembler). So I do like to know that the automation of this process has done a decent job. I once had a compiler that threw a stack frame on every function call, whether data was passed or not. I either took it outside and shot it, or tweaked the optimisation - I forget now - but it did illustrate the wisdom of your observation.

Steve

formatting link
formatting link

Reply to
Steve at fivetrees

I hope it wasn't my compiler. I wrote some pretty stupid ones, way back when.

-Rich

--
Richard Pennington
Email: rich@pennware.com
 Click to see the full signature
Reply to
Richard Pennington

So are COBOL and BASIC despite what Dijkstra said about them. After all he didn't predict that COBOL would go away, he only said that teaching it should be criminalized. And what he said about BASIC did not prevent it from getting a BIG push from you know who. But it did kind of prove Dijkstra's point.

Best Wishes

Reply to
Jeff Fox

... snip ...

This is really only of value (assuming you are using an HLL) to assess the abilities of your compiler etc. under various circumstances. This includes evaluating optimization levels. I think you are really looking for a better understanding of the code generated by apparently simple statements. As a simple example:

while (foo(BAR) && MISH(mash)) { ....

can expand into a horrendous lot of slow code.

I agree about understanding the machine. Make that 'machines'.

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
 Click to see the full signature
Reply to
CBFalconer

... snip ...

You can certainly call such things (for some values of calling protocols), but writing the multiple entry routine in C is going to be highly non-standard.

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
 Click to see the full signature
Reply to
CBFalconer

major part of the work is

On Error Goto is

This is not really a problem in languages, in which you can have labels with descriptive names (but a lot messier, if only numeric labels are available, such as old Fortran and Pascal).

Just put the error handlers with a descriptive label _after_ the normal return path of the function (as with exception handlers), do the clean-up relevant to that error and return a specific error code. In some situations it also can be useful to let the error handlers fall through to the next error handler. Thus, placing the error handler that needs to do most error cleanup first and the last error handler, which does not need any cleanup last just before the return statement, sometimes simplifies the program.

Of course, in the beginning of the functions, the validity of all parameters should be checked and return immediately with an error code if something is wrong.

Only after this, should any resources allocated. In this way, in the actual function logic you have to deal with "unpredictable" errors, such as I/O errors and jump to the appropriate error handler.

By doing this, the function actual logic can be kept simple and readable, the indentation can be kept well below 80 columns, which also makes it easier to use longer, descriptive names, without having to divide each statement to multiple lines or scroll the display.

In the days Dijkstra wrote the article, a large number of programs were really a mess, since simply the main programming languages in those days (Fortran and Cobol) did not offer any real block control structures. The article encouraged compiler writers to include the ideas into the main stream programming languages, which clarified the program logic of new programs.

Unfortunately, the paper also created a hysteria against gotos and in some languages even created all kinds of syntactic sugar, to hide that "dirty" goto word, e.g. when implementing a similar error handling mechanism as described above.

Paul

Reply to
Paul Keinanen

:(

...on the otherhand he is more alive than ever by his legacy and attitude to "authority", reminiscent of Feynmann, another generous soul.

Cheers Robin

Reply to
robin.pain

Before long they will always trust the compiler (or other point and click front end), it can already be seen with a lot of homepages and multi DVD library size applications to type a letter.

In a lot of areas especially PC software the vast majority have already lost the understanding.

--
Paul Carpenter		| paul@pcserv.demon.co.uk
        Main Site
 Click to see the full signature
Reply to
Paul Carpenter

Richard Feynman is another hero of mine... Good chap - but no saint, which somehow made him all the more endearing ;).

Steve

formatting link
formatting link

Reply to
Steve at fivetrees

I do the same thing - and it's not a contravention of structure, since your two examples are indeed equivalent.

Nonono! There be dragons! ;)

Steve

formatting link
formatting link

Reply to
Steve at fivetrees

In our survey we asked 100 people to complete this phrase. What was the most popular answer? ;-)

GOTO _BLANK_

Reply to
Jeff Fox

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.