GoTo Statement

[JLWest]

I have a procedure I can't make work. So I'm thinking of trying it with a GOTO statements.

If I set  {$GOTO ON}  and  {$GOTO OFF} as such  will that turn it off and within the block.

Code: Pascal  [Select][+][-]

1. procedure TForm1.SetSize( ASTRING : String);
2.  var Line : String;
3. begin
4.   {$GOTO ON}
5.     ....
6.    GOTO  Label1:
7.    ....
8.   Label1:
9.    ....
10.    GOTO Label6:
11.    ....
12.   Label6:
13.    ....
14.  {$GOTO OFF}
15. end;
16.  

[Zvoni]

Huh? What's wrong with nested Function/Procedure?

[JLWest]

I posted in beginners. I have never used a nested function/procedure but maybe.

[devEric69]

Labels must be declared below variables: please, read https://wiki.lazarus.freepascal.org/Goto/fr and  https://wiki.lazarus.freepascal.org/Goto .
I really like to use labels inside loop ( and I'm not a newbie in turbo-Pascal ):

Code: Pascal  [Select][+][-]

1. for iFoo:= iThis to iThere the begin
2.   ...\...
3.   j:= calcHere;
4.   if j = 0 then goto lblFooNext;
5.   ...\...
6. lblFooNext:
7. end;

[Zvoni]

I posted in beginners. I have never used a nested function/procedure but maybe.

Post your Procedure you can't get to work, and comment where you want when to jump to

[PascalDragon]

I posted in beginners. I have never used a nested function/procedure but maybe.

Nested functions/procedures are simple:

Code: Pascal  [Select][+][-]

1. procedure Outer;
2. var
3.   a: LongInt;
4.  
5.   procedure Inner1;
6.   begin
7.     b := 42;
8.   end;
9.  
10. var
11.   b: LongInt;
12.  
13.   function Inner2: LongInt;
14.   begin
15.     Result := b + a;
16.   end;
17.  
18. var
19.   c: LongInt;
20. begin
21.   Inner1;
22.   b := 21;
23.   c := Inner2;
24. end;

Nested functions/procedures are able to access variables of the surrounding routine that were declared above them. So here Inner1 has access to a and Inner2 has access to a and b (and the surrounding routine has access to a, b and c).

Labels must be declared below variables: please, read https://wiki.lazarus.freepascal.org/Goto/fr and  https://wiki.lazarus.freepascal.org/Goto .

They don't need to be declared below variables, but they do need to be declared.

[marcov]

You don't give an exact errormessage. Also you don't declare labels with the LABEL statement, as the wiki does.

[JLWest]

Thanks to all.

I have a procedure with goto's working. My example was poor.

I'm trying to parse some text, which would fit into a 70 character window. If I can't get it working I'll post a demo of it.

[Blade]

I really like to use labels inside loop ( and I'm not a newbie in turbo-Pascal ):

I use them too, from time to time, like for certain conditions to exit a long function.  Don't see anything wrong with it, as long as the person doesn't get excessive, and makes sure that the usage is clear and the code is easy to follow.

When a person is a beginner, it might be good advice to know that goto is one way among many ways, not the main way or always the "goto" for getting out of any coding problems.

[Zath]

From the earliest days of Delphi, we are told the Goto is not to be used, it is dangerous because you can jump out of anywhere to anywhere leaving all sorts of things open behind you.

It was fine in Basic when things were often sequential but not in today's Delphi/Pascal when there are so many other ways to achieve the same result.

[Zvoni]

From the earliest days of Delphi, we are told the Goto is not to be used, it is dangerous because you can jump out of anywhere to anywhere leaving all sorts of things open behind you.

It was fine in Basic when things were often sequential but not in today's Delphi/Pascal when there are so many other ways to achieve the same result.

What i said: What's wrong with nested Functions?
I don't think i have used a Goto in some 15 years of VB6/VBA, and i haven't used it once in 3 years of FPC/Lazarus....
Goto just invites Spaghetti (though i do like Spaghetti with Bolognese.....)

[MarkMLl]

From the earliest days of Delphi, we are told the Goto is not to be used, it is dangerous because you can jump out of anywhere to anywhere leaving all sorts of things open behind you.

It was fine in Basic when things were often sequential but not in today's Delphi/Pascal when there are so many other ways to achieve the same result.

Short response: there are places where GOTO is valuable, but the OP's problem is not one of them: he needs to find a book on elementary Pascal programming.

Longer response: Dijkstra's criticism of GOTO was actually sensationalised by Wirth, and Dijkstra himself later remarked on the religious fervour with which some people try to avoid the construct. More recent languages tend to replace GOTO with one or more of break/exit/continue/next, but I've seen those derided as being no better.

I fully accept that unstructured control transfers and premature function termination jeopardise attempts at formal analysis and proof (term used in the strict mathematical sense) of correctness, but in practical terms we're all trying to get stuff done here and the type checking pioneered by Pascal (and gradually adopted by most successor languages) provides far more of a boost to productivity than do most "pure science" languages which are so incomplete as to be barely usable for Real World problems.

MarkMLl

[440bx]

The presence of a GOTO means one or more of the following things:

1. the programmer still has things to learn about programming (or is too lazy to spend the time to figure out a decent algorithm.)

2. the algorithm is poorly designed or poorly implemented or, both.
3. the language lacks basic control flow structures (e.g, SNOBOL)

The irony is, who needs a GOTO these days when exceptions, i.e, GOTO on steroids, are not only available but, objects of pride for some programmers and, are as common today as GOTOs were in "the good GOTO days".

Sometimes Computer Science makes great progress, unfortunately, sometimes in the wrong direction.

[marcov]

My Delphi code contains two gotos. They are in speed sensitive code jumping out of a double nested IF (and yes, that is faster, or at least till D2009, when I lsst tested).

The code strings runs together into BLOBs.

[ccrause]

Goto just invites Spaghetti

IMHO the hype against GOTO should not be about avoiding GOTO, rather on putting effort into streamlining of logical flow (rather eat spaghetti than leave it in code form).  I've seen various innovative ways of programming spaghetti while cleverly avoiding the actual use of GOTO.  One method is to use an endless loop with various combinations of break, continue and exit statements that really mess with my understanding of the logical flow.  If this becomes necessary to express the logic, it may be time to consider other techniques, for example a state machine.

Apologies to JLWest for following this tangent.