Re: goto

new topic     » topic index » view thread      » older message » newer message

On 7 Jan 2001, at 20:18, Graeme wrote:

> At 06:48 PM 06/01/01 -0600, you wrote:
> >On 6 Jan 2001, at 18:43, Al Getz wrote:
> >
> >> Hey there Kat,
> >>
> >>   I ran into problems like that too.  I'm not so sure a goto is the answer
> >> anymore though.  I have seen how that disrupts the program read-through
> >> flow, and now favor the 'continue' statement and possibly an "exit_all"
> >> statement. Compare the following two code fragments:
> >
> >So you'd rather have several versions of exit than a goto?? ouch. I still say
> >the goto is better than all those flags you set and tested in the examples
> >you gave. And it would be cleaner and faster, especially in a stack of code
> >like a case table, since we don't have case (and i am not saying this is
> >great coding style):
> >
> >if a then do something  goto procend end if
> >if b then do something  goto procend end if
> >if c then do something  goto procend end if
> >if d then do something  goto procend end if
> >if e then do something  goto procend end if
> >signal(error)
> >:procend
> >
> >i know it can be rewritten as
> >
> >if a then do something
> >elseif b then do something
> >elseif c then do something
> >elseif d then do something
> >elseif e then do something
> >else signal(error)
> >end if
> >
> >But don't you see the inherent goto in the machine code in the 2nd
> >example? So why have exit and exit_all and continue, when the simple
> >goto can replace them all, and it's there already?
> >
> >Kat
>
>
> It can also be re-written as:
>
> if a then do something return end if
> if b then do something return end if

The return tells me you have it in a subroutine all it's own, and with it
calling overhead of the procedure or function.

Kat

new topic     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu