OpenEuphoria

Re: Conceptual problem solved by GOTO

• Posted by Fernando Bauer <fmbauer at hot?ail?com> Jun 07, 2008
• 752 views

ken mortenson wrote:
> 
> 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
> 
Thanks Ken for your implementation!  It solves the conceptual problem, however
it seems that it creates another problem: for each nested-if it can be necessary
to duplicate a block of code. And you have to maintain these blocks equal. So, it
seems to me that this implementation does not follow the "Don't Repeat Yourself"
principle.

[snipped]

Regards,
   Fernando