Greetings:
Running the code below we can see that the Finally works correctly
with the exit statement:
Program Test;
{$mode objfpc}{$H+}
Procedure x(i :Integer);
Begin
Try
Begin
WriteLn('Running Try');
if (i=2) then exit;
WriteLn('After if(i=2)');
End;
Finally
WriteLn('Finally reached');
End;
End;
// Main program
Begin
WriteLn('Ini');
x(2);
WriteLn('End.');
End.
One example of label/goto and de-structuring code is below (in C). The
statement "return(res)" in C returns immediately the value of res.
/* This func return an integer number or -1 if error */
int do_something(void)
{
/* vars */
int ret;
resourceA *resA;
resourceB *resB;
resourceC *resC;
resourceD *resD;
/* code */
res = -1; // Error
// Alloc resources
resA=alloc_resourceA();
/* This funcs return a pointer or NULL (0) if error. */
if (! resA) return(-1); // Error. There are no resources to alloc resA.
resB=alloc_resourceB();
if (! resB) goto puke;
resC=alloc_resourceC();
if (! resC) goto vom;
resD=alloc_resourceD();
if (resD) goto throwout;
// Do things
........ code .......
........ code .......
......... put some value in res to return .....
// Free resources on error area
throwout:
free_resourceD(resD);
vom:
free_resourceC(resC);
puke:
free_resourceB(resB);
// return
return(res);
}
The labels say my oppinion of indiscriminate use of goto.
The correctly structured code goes below:
/* This func return an integer number or -1 if error */
int do_something(void)
{
/* vars */
int ret;
resourceA *resA;
resourceB *resB;
resourceC *resC;
resourceD *resD;
/* code */
res = -1; // Error
resA=alloc_resourceA();
/* This funcs return a pointer or NULL (0) if error. */
if (resA)
{
resB=alloc_resourceB();
if (resB)
{
resC=alloc_resourceC();
if (! resC)
{
resD=alloc_resourceD();
if (resD)
{
// Do things.
........ code .......
........ code .......
......... put some value in res to return .....
free_resourceD(resD);
};
free_resourceC(resC);
};
free_resourceB(resB);
};
free_resourceA(resA);
};
return(res);
};
Well, bad organized (no sections), the resources are scatteres
around (more dificult to debug) and a lot recursive "if"s
(make it dificult to firgure at the first what the code is doing). .
But it is a beautiful piece of code.
The two codes above will generate very close asm code, so they will
have almost the same performance.
So you can choose: Simple, ugly and mantainable or elegant and and
dificult to understand. All supposing you know how to use correctly the
labels not doing some nasty thing with it.
Imagine now the code above with 30 or 40 resources. At
least in my oppinion it justify the use of some gotos.
But everyone can choose the best way to program. The two ways work
very well after some debugging. It is just a matter of choice.
Ric.
On Saturday 19 April 2008, Zaher Dirkey wrote:
> I hate exit when i try to improve a procedure
>
> some code
> if (b) then
> exit;
> some code
>
> for long procedures i cant notice exit here and add some resource or memory
> uses
>
> AnObject := TAnObject.Create;
> try
>
> some code
>
> if (b) then
> exit;
>
> some code
>
> finally
> AnObject.Free;
> end;
>
> Now Exit leave the procedure without freeing "AnObject".
> We need a new Exit keyword to jump to Finally section (I do not think
> Abort is useful here).
>
> On Fri, Apr 18, 2008 at 7:58 PM, Ricardo Aguiar <[EMAIL PROTECTED]>
wrote:
> > Hi!
> >
> > GCC and almost all the other C implementations have the goto
> > statement. It is just ugly and dangerous use it many times in a
> > program. But IMHO any compiled language should have goto
> > because many times we need to do unstructured code to run
> > fast (in complex search code for example). So goto is not a
> > matter of principles about the language, it is just a "dirty and
> > ugly" approach to solve problems that many times are useful.
> >
> > Anyway in my oppinion a very complex program in a structured
> > language with more than a dozen gotos should not be considered
> > a good pratice (except for kernel internals and things like this -- that
> > many times would be a lot more complex without the gotos).
> >
> > Ric.
> >
> > On Thursday 17 April 2008, Marco Alvarado wrote:
> > > The problem of GOTO is that C doesn't have one. If C had one, and
> > > Pascal didn't have a GOTO, they would blame Pascal for not having it.
> > > In assembler GOTOs make a lot of sense (i.e. JMP and Jxx), and it's
> > > weird C doesn't have one, after all C tries to be the lowest level of
> > > the highest level languages. It's great Pascal have both high and low
> > > level features.
> >
> > _______________________________________________
> > fpc-pascal maillist - fpc-pascal@lists.freepascal.org
> > http://lists.freepascal.org/mailman/listinfo/fpc-pascal
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
