GOTO is alive and well. Dijkstra, eat my pants - Page 2

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: GOTO is alive and well. Dijkstra, eat my pants
On Wed, 09 Jun 2004 23:55:19 +0100, Joe

Quoted text here. Click to load it
Maybe. Maybe not. It varies depending on the rest of the program. The
third answer is more likely.  It's off-topic here, in any case. You
might ask on a newsgroup which deals with you particular compiler, but
don't be surprised if you get the same answers.

--
Al Balmer
Balmer Consulting
We've slightly trimmed the long signature. Click to see the full one.
Re: GOTO is alive and well. Dijkstra, eat my pants

Quoted text here. Click to load it

Sorry - wrong newsgroup. It's not necessarily off-topic here. The rest
of my answer stands, though.

--
Al Balmer
Balmer Consulting
We've slightly trimmed the long signature. Click to see the full one.
Re: GOTO is alive and well. Dijkstra, eat my pants

Quoted text here. Click to load it

Better yet, try it and see.

Quoted text here. Click to load it

--
Grant Edwards                   grante             Yow!  Hand me a pair of
                                  at               leather pants and a CASIO
We've slightly trimmed the long signature. Click to see the full one.
Re: GOTO is alive and well. Dijkstra, eat my pants
This is off topic...

Quoted text here. Click to load it

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

Quoted text here. Click to load it

--
Richard Pennington
Email: snipped-for-privacy@pennware.com
We've slightly trimmed the long signature. Click to see the full one.
Re: GOTO is alive and well. Dijkstra, eat my pants

Quoted text here. Click to load it

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.)

Quoted text here. Click to load it

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!
We've slightly trimmed the long signature. Click to see the full one.
Re: GOTO is alive and well. Dijkstra, eat my pants

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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
Quoted text here. Click to load it

--
Richard Pennington
Email: snipped-for-privacy@pennware.com
We've slightly trimmed the long signature. Click to see the full one.
Re: GOTO is alive and well. Dijkstra, eat my pants
Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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
http://www.fivetrees.com
http://www.sfdesign.co.uk



Re: GOTO is alive and well. Dijkstra, eat my pants



Quoted text here. Click to load it

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

-Rich
Quoted text here. Click to load it

--
Richard Pennington
Email: snipped-for-privacy@pennware.com
We've slightly trimmed the long signature. Click to see the full one.
Re: GOTO is alive and well. Dijkstra, eat my pants
Quoted text here. Click to load it
... snip ...
Quoted text here. Click to load it

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 ( snipped-for-privacy@yahoo.com) ( snipped-for-privacy@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
We've slightly trimmed the long signature. Click to see the full one.
Re: GOTO is alive and well. Dijkstra, eat my pants

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

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

--
Paul Carpenter        | snipped-for-privacy@pcserv.demon.co.uk
<http://www.pcserv.demon.co.uk/ Main Site
We've slightly trimmed the long signature. Click to see the full one.
Re: GOTO is alive and well. Dijkstra, eat my pants

Quoted text here. Click to load it

Worse than that, they may start trusting the assembler or even trust
that the hardware works as defined.  :-)

Tom



Re: GOTO is alive and well. Dijkstra, eat my pants

Quoted text here. Click to load it

Of course they would never do that :-^
They have only be worried about creating a good product that works
for the last n years of course :-)

Note seen comment recently on computer security in IEEE Computer Society
magazine this month, where someone quotes about PC Firewall products
that not enough testing and rushing to market abounded.

--
Paul Carpenter        | snipped-for-privacy@pcserv.demon.co.uk
<http://www.pcserv.demon.co.uk/ Main Site
We've slightly trimmed the long signature. Click to see the full one.
Re: GOTO is alive and well. Dijkstra, eat my pants
Quoted text here. Click to load it
Thanks.  My question is more on the general view (I use GCC on Linux,
UNIX, but sometimes use ARM ADS on some projects as well).

I always worry about putting "break" in for loop and while loops because
I am not sure if it is a bad practice (as using goto). So I only use it
in case statements.  Should I avoid "break" if possible?

Joe

Re: GOTO is alive and well. Dijkstra, eat my pants
Quoted text here. Click to load it

No. By definition, it only ends the current loop - so it doesn't break
structure. If, OTOH, it jumped across two or more constructs...

Steve
http://www.sfdesign.co.uk
http://www.fivetrees.com



Re: GOTO is alive and well. Dijkstra, eat my pants

...
Quoted text here. Click to load it

No, it's a good thing, if you know what I mean. But if you have a
large set of cases, try to group those that end in 'break' together
and those that end in 'return' together, et cetera. - RM


Re: GOTO is alive and well. Dijkstra, eat my pants
Quoted text here. Click to load it
... snip ...
Quoted text here. Click to load it

break (and continue) preserve more information about loop states
than does a blunt goto.  Therefore it is easier to optimize code
using them than code using goto.

As far as clarity is concerned, that is another matter IMO.  I
consider that gotos used only to replace the effects of break and
continue would be clearer, because they would contain a clear
identification of the place gone to, and that place would in turn
be clearly identified with a sited label.

My advice is the same as for gotos - use them when needed, but
avoid the need.  I think your instincts are sound.  Now you may
have some reasons to back them up.

--
Chuck F ( snipped-for-privacy@yahoo.com) ( snipped-for-privacy@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
We've slightly trimmed the long signature. Click to see the full one.
Re: GOTO is alive and well. Dijkstra, eat my pants

Quoted text here. Click to load it

OTOH, the goto is not constrained to have any meaning with respect to
the construct it's used in, where a break or continue has a clearly
defined effect with respect to that construct.
Quoted text here. Click to load it

--
Al Balmer
Balmer Consulting
We've slightly trimmed the long signature. Click to see the full one.
Re: GOTO is alive and well. Dijkstra, eat my pants
On Thu, 10 Jun 2004 22:15:26 +0100, Joe

Quoted text here. Click to load it

Using break is an accepted practice.   Stylistically you should take
care to call attention to a break with a comment or by setting it off
in braces because the next person reading your code could easily
overlook it.

Someone once suggested to me that, rather than use "break", it was
clearer to set a loop termination flag and use "continue" to force the
exit.  This isn't totally crazy because in many CPU architectures it
is more efficient to code the test at the end of a loop and branch
backward to the beginning if necessary.  Using "break" is more
efficient for exiting a single loop because it is unconditional, but
the "continue" technique can easily be used to exit from nested loops
whereas the "break" cannot.

I have only rarely used the "continue" method, but I always keep it in
mind in case it happens to fit the pattern of the code I am writing.

George
--
Send real email to GNEUNER2 at COMCAST o NET

Re: GOTO is alive and well. Dijkstra, eat my pants

Quoted text here. Click to load it

In general, error recovery tends to take a nice clean architecture and
make a mess of it.  One reason why too many people ignore it (along with
the fact that in many cases there isn't a clean recovery method possible).

Any code (error recovery or other) needs to be judged by clarity and
readability.  It's possible to create very unclear but properly
structured code or clear code with gotos.

Tom


Re: GOTO is alive and well. Dijkstra, eat my pants

Quoted text here. Click to load it

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
We've slightly trimmed the long signature. Click to see the full one.

Site Timeline