GOTO is alive and well. Dijkstra, eat my pants

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

...

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

... snip ...

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.

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

Yes, naughty is loveable, but saintliness is... don't ya just hate it! On the otherhand, a saint usually a pain in the arse (to "authority").

Cheers Robin

(excluding

Completely agreed.

In many situations where such dilemmas occur, however, a (guess what!) state machine will improve readability and hence maintainability, and make such issues irrelevant.

Steve

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.

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

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

Tom

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.

Humm, found the code for my BIOS, concerning memory testing:

void memtest(void)

unsigned int kbm; int escpressed;

escpressed = 0; for (kbm = 0; kbm < MAXMEM; kbm++) {

printf("\r%d OK\r", kbm); if (keypressed() == 0x1b) then escpressed = 1; if (!escpressed) delaymillesecond(100);

... snip ...

Which is obviously simply a delay mechanism. This is one facet of a bios memtest that is required to allow disks to spin up.

And that's all the above code does; it displays consecutive numbers at 1ms intervals. No memory test is ever performed.

Too dry to be funny, eh ?

Scott Moore wrote in news:toUyc.93499$Ly.43797@attbi_s01:

Made me smile :)

Peter.