Recent

Author Topic: GoTo Statement  (Read 2755 times)

Zvoni

  • Hero Member
  • *****
  • Posts: 739
Re: GoTo Statement
« Reply #15 on: September 15, 2021, 11:48:39 am »
If we're honest, the 99% use-case for GOTO is Error-handling.

I've seen enough C-Code, where they use a conditional GOTO to jump to a label to do some clean-up (usually at the end of a Function/Procedure).

440bx is correct with our Try..Except/Finally --> much more elegant.

OTOH, everytime i ported C-Code with a GOTO-Error-Cleanup i solved it without a Goto but with a nested Function and an Exit-Statement.
Much cleaner IMO.
One System to rule them all, One IDE to find them,
One Code to bring them all, and to the Framework bind them,
in the Land of Redmond, where the Windows lie
---------------------------------------------------------------------
People call me crazy, because i'm jumping out of perfectly fine aircraft

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 9594
  • FPC developer.
Re: GoTo Statement
« Reply #16 on: September 15, 2021, 11:53:31 am »
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.

This is the way Wirthian languages evolved, not just Pascal, but also e.g. Modula-2 loop ..end exit .

I don't see anything wrong with it, unless the problem suits a more high level solution (like a statemachine)

Quote
If this becomes necessary to express the logic, it may be time to consider other techniques, for example a state machine.

The most important bit is that everything is just guidelines, not absolute, hard rules. And normal procedure/methods that are extremely long are also a sign that is something wrong.

And yes, a statemachine can be a solution in many cases.

devEric69

  • Hero Member
  • *****
  • Posts: 614
Re: GoTo Statement
« Reply #17 on: September 15, 2021, 11:54:38 am »
Perso., I'm using goto in 2 cases:
- refactoring of very, very degraded, even unintelligible source code, which must be shunted little by little piece towards a replacement refactoring (e.g.: code with only one var variant variable: yes, yes, it happens).
- to compensate for the lack of semantic of the continue; statement (continue; yes, but why?) in very large loops (such as data cohort processing), when the latter statement appears several times.
use: Linux 64 bits (Ubuntu 20.04 LTS).
Lazarus version: 2.0.4 (svn revision: 62502M) compiled with fpc 3.0.4 - fpDebug \ Dwarf3.

440bx

  • Hero Member
  • *****
  • Posts: 2502
Re: GoTo Statement
« Reply #18 on: September 15, 2021, 12:49:27 pm »
440bx is correct with our Try..Except/Finally --> much more elegant.
I'm afraid you misunderstood me.  I consider most use of exceptions as being much worse than the majority of GOTOs.  They are in the class of setjmp/longjmp, i.e, programming atrociities.

The only time I consider the use of exceptions to be acceptable is when dealing with resources - usually memory - that is not managed by the executable that is reading (or writing) it.  The other time when it is _temporarily_ acceptable is to validate the size of the parameters received from the caller and, that is usually in an "{$ifdef debug_check_params} ... {$endif} block.  IOW, the final code does _not_ include the exception handlers.


FPC v3.0.4 and Lazarus 1.8.2 on Windows 7 64bit.

JLWest

  • Hero Member
  • *****
  • Posts: 1054
Re: GoTo Statement
« Reply #19 on: September 15, 2021, 07:55:30 pm »
@Thanks All

All this is a nice theoretical discussion. However, it doesn't solve the problem with parsing, formatting and displaying a string in a memo at an exact location based on the composition and length of the string.
 
Yea, I could get a book, study nested functions and give it a go that way. But I think it's a logic or algorithm problem that I can't figure out.

What I'm trying to do is complicated (for me anyway) with a lot of variables.
 
FPC 3.2.0, Lazarus IDE v2.0.4
 Windows 10 Pro 32-GB
 Intel i7 770K CPU 4.2GHz 32702MB Ram
GeForce GTX 1080 Graphics - 8 Gig
4.1 TB

440bx

  • Hero Member
  • *****
  • Posts: 2502
Re: GoTo Statement
« Reply #20 on: September 15, 2021, 08:14:30 pm »
All this is a nice theoretical discussion. However, it doesn't solve the problem with parsing, formatting and displaying a string in a memo at an exact location based on the composition and length of the string.
if you showed a sample of the string you want to parse along with the result you'd like to obtain, you'd get less theory and more code.

IOW, you're digging your own theoretical book.
FPC v3.0.4 and Lazarus 1.8.2 on Windows 7 64bit.

JLWest

  • Hero Member
  • *****
  • Posts: 1054
Re: GoTo Statement
« Reply #21 on: September 15, 2021, 09:29:02 pm »
@440bx your right

Actually I'm working on providing a demo of the problem.
FPC 3.2.0, Lazarus IDE v2.0.4
 Windows 10 Pro 32-GB
 Intel i7 770K CPU 4.2GHz 32702MB Ram
GeForce GTX 1080 Graphics - 8 Gig
4.1 TB

MarkMLl

  • Hero Member
  • *****
  • Posts: 3251
Re: GoTo Statement
« Reply #22 on: September 15, 2021, 09:48:05 pm »
Actually I'm working on providing a demo of the problem.

It really would help enormously. However if I could make one point: Pascal was a close derivative of ALGOL-60, and both allow nested procedures. It's more recent languages (C etc.) which have, generally speaking, omitted them.

MarkMLl
Turbo Pascal v1 on CCP/M-86, multitasking with LAN and graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

 

TinyPortal © 2005-2018