OpenEuphoria

Re: Conceptual problem solved by GOTO

• Posted by ken mortenson <kenneth_john at yahoo??om> Jun 06, 2008
• 744 views

I keep seeing people make the same false claims about GOTO over and over.

The issue regarding GOTO vs. structured code IS NOT SPEED.  Yes, calling a
routine to refactor code makes the refactored code slower... but you NEVER
have to call a sub routine.  The tradeoff without using functions is SIZE
not SPEED.  

I've identified some lines of .. some code here .. with (A) and (B)

Fernando Bauer wrote:
> procedure proc1()
> if cond1 then
>    .. some code here ..
>    if cond2 then
>       .. some code here ..
>       if cond3 then
>          .. some code here ..
>          goto OUT
>       end if
>       .. some code here .. (A)
>    end if
>    .. some code here .. (B)
> end if
> OUT:
> .. some code here ..
> end procedure

You will note in the following that line (B) is now inline in two places
(more SIZE) but only executes once (same SPEED)  It should be exactly the
same speed for the if to branch to the else rather than the end if.

procedure proc1()
if cond1 then
   .. some code here ..
   if cond2 then
      .. some code here ..
      if cond3 then
         .. some code here ..
      else
         .. some code here .. (A)
         .. some code here .. (B)
      end if
   else
      .. some code here .. (B)
   end if
end if
.. some code here ..
end procedure

> Now, without GOTO, we are forced to (mis)use a loop construct (for-loop,
> while-loop)
> where there is NO loop.
> Conceptually, IMHO this makes no sense.
> To avoid the conceptual problem we could use flags, but IMHO this is even
> worst.

You are not forced to misuse a loop.  No flags either.

If your basing your desire on GOTOs because of speed you are using a false
premise and should rethink it.

Do I prefer this refactoring?  No.  That's why I use subroutines.  But if
I need speed I just have to make the tradeoff with code size.