Funzioni: Come uscire correttamente da una funzione? Quanti valori restituisce?

[AlexLazarus]

Un paio di domande un po' sceme (non tutti sono perfetti).

1) In Visual Basic per uscire da una Funzione c'è Exit Function. In Lazarus c'è "solo" Exit" oppure ho capito male?. Nel caso sia all'interno di un ciclo For ... Do ... End (che non si completa a causa dell'Exit al suo interno) come uscirne correttamente senza lasciare cicli incompleti, causa di possibili bug?

2) Forse ricordo male, ma mi pare che era possibile che una funzione restituisse non un solo valore, ma due (o più). Ho fatto ricerche sul web ma sembra che sia possibile restituire un solo valore. E' così?

[bonmario]

Ciao,
per uscire da un ciclo, puoi usare "Break".

Ci sarebbe anche "Continue" che permette di evitare le righe successive di un ciclo, e di passare all'elemento succecssivo ... almeno credo ... l'ho usato una sola volta, e non ricordo di preciso come funziona ...
Qui comunque la sua descrizione ufficiale: https://www.freepascal.org/docs-html/rtl/system/continue.html


Per quanto riguarda invece i valori di ritorno, di una funzione, quello restituito da "Result", è solo uno. Però se la tua funzione la dichiari ad esempio così:

Codice: [Seleziona]

 function  ScompattaBasDat(var CodExit:Integer; Applicativo, Versione:String; var DirBase:String):Boolean; 

Se valore delle 2 variabili CodExit e DirBase, verrà modificato all'interno della funzione, rimarrà quello anche nel resto del programma. Per le altre 2 variabili, invece non sarà così. La differenza fa il "var " messo prima nella dichiarazione di questi 2 parametri.


Ciao, Mario

[DragoRosso]

Esempio banale di ciclo for con "break" e "continue"

Codice: [Seleziona]

var i, somma: integer;

somma := 0;
for i := 0 to 100 do
  begin
     if i = 50 then break;                   //break fà uscire dal ciclo prima anche se doveva ciclare fino a 100
     if (i mod 2) > 0 then continue;    //continue rimanda al end del for che quindi continua con la prossima iterazione
     somma := somma + i;   //somma solo i numeri pari 
  end;
ShowMessage('La somma dei numeri pari da 0 a 49 (a causa del break) è: '+somma.ToString);

Per quello che riguarda i "risultati" delle funzioni, i parametri come ti accennava @bonmario possono essere loro stessi delle variabili IN / OUT.

Però, se ti serve un risultato con molteplici valori sarebbe meglio usare un record:

Codice: [Seleziona]

type TRisultato = record
    Risult1: boolean;
    Risult2: integer;
    Risult3: string;
    ......
    ......
end;

var Risultato: TRisultato

function  ScompattaBasDat(const CodExit:Integer; const Applicativo, Versione:String; const DirBase:String): TRisultato; 


Risultato := ScompattaBasDat(..........);

La parolina "const" inserita nella definizione dei parametri della funzione consente di definire costante quel valore e nella funzione l'assegnazione di un valore al parametro verrà segnalato come errore in fase di compilazione.

Inoltre consente di ottimizzare e velocizzare il codice nella gestione dello stack.

Ciao

[nomorelogic]

2) Forse ricordo male, ma mi pare che era possibile che una funzione restituisse non un solo valore, ma due (o più). Ho fatto ricerche sul web ma sembra che sia possibile restituire un solo valore. E' così?

una funzione restituisce 1 solo valore
tuttavia puoi definire dei parametri "out" così che puoi averne quanti ne vuoi

Codice: [Seleziona]

function TestPositivo(const AValue: integer; out Message: string): boolean;
begin
  result := Avalue > 0;
  if result then
    Message := 'il numero è positivo';

end;

Edit:
https://www.freepascal.org/docs-html/ref/refsu66.html

[bonmario]

Occhio però che "out" e "var", hanno un comportamento simile, ma diverso:
https://docwiki.embarcadero.com/RADStudio/Alexandria/en/Parameters_%28Delphi%29

Io preferisco usare "var", così se in manutenzioni successive dovessi dover passare un valore di inizializzazione, non devo stare a guardare come avevo dichiarato la funzione/procedura

Ciao, Mario

[DragoRosso]

E' sorta, ancora tempo fà una diatriba sull'uso della definizione OUT nei parametri, legata allo specifico fatto che la variabile passata sempre come riferimento, verrebbe messa in una condizione di "deinizializzazione" all'ingresso della procedura / funzione.

Questo ha generato una serie di problematiche che rende l'uso di OUT alquanto desueto. Qui stiamo parlando di Delphi dove ci sono discussioni su ciò, su Lazarus non ho conoscenza del funzionamento intrinseco di OUT e sulle sue eventuali ripercussioni. In Delphi non mi è mai capitato nelle interfacce NON COM di avere una definizione di OUT nei parametri, almeno negli ultimi anni.

Ho usato OUT solo nelle interfacce COM (cioè ActiveX) dove tale uso ero perfettamente in linea con la tecnica COM (gli oggetti, le variabili e le interfacce COM seguono regole simili alla programmazione normale, ma fanno uso di alcune peculiarità definite dalla tecnologia COM appunto).

Il riferimento per l'uso di OUT in FPC è: https://www.freepascal.org/docs-html/ref/refsu66.html

Edit:
https://www.freepascal.org/docs-html/ref/refsu66.html

P.S.: OOPS scusa @nomorelogic, non avevo fatto attenzione alla tua modifica al post.

Ciao

[DragoRosso]

Giusto per curiosità ho provato a fare girare una funzione con la definizione di OUT nei parametri.
Sia in Delphi che in Lazarus e .... sorpresa il risultato è esattamente lo stesso, ossia funziona esattamente come una VAR (in Delphi non dà alcun avviso ... almeno in Lazarus ti avvisa che forse la variabile non è inizializzata).

Probabilmente le discussioni e le problematiche relative alla gestione delle variabili "managed" (come le string) hanno portato gli sviluppatori dei compilatori a più miti consigli.

Per testare create un applicazione nuova in Lazarus, fate doppio click sulla FORM e poi sovrascrivete TUTTO il codice il seguente, vedrete che la variabile Occhio che vale 5 mantiene il suo valore anche dentro la funzione e al ritorno della funzione vale esattamente come fosse stata definita come VAR.

Codice: [Seleziona]

unit Unit1;

{$mode objfpc}{$H+}

interface

uses
  Classes, SysUtils, Forms, Controls, Graphics, Dialogs;

type

  { TForm1 }

  TForm1 = class(TForm)
    procedure FormCreate(Sender: TObject);
  private

  public

  end;

  function Prova(out tipo: integer): integer;

  var
    Form1: TForm1;

  implementation

  {$R *.lfm}

  function Prova(out tipo: integer): integer;
  begin
    result := 0;
    result := result + tipo;
    tipo := tipo + tipo;
  end;

  procedure TForm1.FormCreate(Sender: TObject);
  var occhio: integer;
  begin
    Occhio := 5;
    ShowMessage(Prova(occhio).ToString+' / '+Occhio.ToString);
  end;

end.

[AlexLazarus]

Grazie per le risposte, che esaminerò con calma e gesso. Tuttavia...
Tuttavia, forse mi sono espresso male. Per "uscire da una funzione" intendevo proprio abbandonare la funzione in uno o più punti e NON uscire da un semplice ciclo posto all'interno di una funzione.
A livello puramente schematico intendo questo:

Codice: [Seleziona]

Funzione (Mio_Calcolo): String

Begin

 Begin
	Inizia primo calcolo
	Se succede questo, alla fine vai al secondo calcolo
	altrimenti EXIT dalla funzione
end;

 Begin
	Inizia secondo calcolo
	Se succede quest'altro, alla fine vai al terzo calcolo
	altrimenti EXIT dalla funzione
 end;

Begin
	Inizia terzo calcolo
	Se succede quest'altro ancora, vai alla fine
	altrimenti EXIT dalla funzione
 end;
 
 Mio_Calcolo:=  'Ecco i risultati:' // Risultati elaborati dalla funzione se tutto è OK

End;

Vi anticipo che, prima che leggessi le vostre risposte, avevo già scritto un programma del tipo indicato, inserendo EXIT in più punti, e funziona!
Il mio dubbio era se quell'Exit possa provocare un evento ricorsivo, che prima o poi degenera in errore.
Ricordo che nel Commodore64(!!) era facile distrarsi e fare un errore del genere:

Codice: [Seleziona]

100 GoSub 200
200 GoTo 100

OUT OF DATA ERROR // Mi pare che - a causa dell'esaurimento dello stack, ci fosse una segnalazione simile, non ricordo di preciso

[bonmario]

Ciao,
io "Exit" lo uso il meno possibile.
Il motivo è semplice: supponi che all'inizio della funzione crei un oggetto, e lo distruggi alla fine.
Se in mezzo fai una Exit, l'oggetto rimane in memoria.
Io preferisco usare una booleana, che inizializzo a false, Valorizzo a True quando serve, e condiziona tutti i blocchi.
Il tuo esempio diventerebbe così:

Codice: [Seleziona]

Funzione (Mio_Calcolo): String

Funzione (Mio_Calcolo): String

var VFEsci:Boolean = False;

Begin

if (not VFEsci) then Begin
    Inizia primo calcolo
    Se succede questo, alla fine vai al secondo calcolo
    altrimenti VFEsci:=True
end;

if (not VFEsci) then Begin
    Inizia secondo calcolo
    Se succede quest'altro, alla fine vai al terzo calcolo
    altrimenti VFEsci:=True
 end;

if (not VFEsci) then Begin
    Inizia terzo calcolo
    Se succede quest'altro ancora, vai alla fine
    altrimenti VFEsci:=True
 end;
 
 Mio_Calcolo:=  'Ecco i risultati:' // Risultati elaborati dalla funzione se tutto è OK

End;

[DragoRosso]

Scusami, avevo frainteso la domanda.

L'uscita da una funzione avviene genericamente in tre modi:

1) Naturale svolgimento del flusso sino all'ultima istruzione (end) della funzione stessa;

2) Tramite "exit";

3) A seguito di un errore (eccezione) non gestito.

Ci sono altri modi, come exitprocess, Halt, .... ma non ha molto senso discutere su questi.

La tecnica moderna diciamo che privilegia quella che si chiama programmazione strutturata, ossia la programmazione che lavora a blocchi nidificati.

Quindi niente GOTO (anche se ancora ammesso nel linguaggio Pascal, io l'abolirei).

Tendenzialmente quindi l'uso di "exit" (ma come anche di break, continue, etc ...) dovrebbe rimanere comunque una possibilità da ponderare e che non deve essere usata "come il pane".

L'uso di Exit è comunque sempre lecito, facendo conto che deve assolutamente prendere in considerazione, come accennava @bonmario, la logica della funzione stessa. Se crei qualcosa di locale dentro la funzione, devi distruggerla prima dell'uscita. E in questo caso Exit potrebbe non esserti di aiuto.

Vorrei anche ricordare che è importante che le eccezioni non si propaghino, ossia non escano dai confini della funzione (a meno che questo non sia voluto), perchè altrimenti si possono generare situazioni di LEAK o peggio ancora di "blocco" del codice.

Ultima nota tecnica è che il Pascal "pretende" che sia la funzione chiamata a bilanciare lo stack, ossia lo stack dovrebbe essere "pareggiato" tra l'inizio della funzione e la sua uscita.

Il mio dubbio era se quell'Exit possa provocare un evento ricorsivo, che prima o poi degenera in errore.
Ricordo che nel Commodore64(!!) era facile distrarsi e fare un errore del genere:

Codice: [Seleziona]

100 GoSub 200
200 GoTo 100
OUT OF DATA ERROR // Mi pare che - a causa dell'esaurimento dello stack, ci fosse una segnalazione simile, non ricordo di preciso

Il problema delle chiamate ricorsive (una funzione che chiama se stessa) esiste in tutti i linguaggi, in quanto anche nei sistemi moderni lo "stack" non è infinito e quindi se non si interrompe la ricorsione prima o poi verrà generata una eccezione di esaurimento dello stack (o di risorse), generalmente fatale anche per il sistema operativo.

Ciao

[AlexLazarus]

... Se crei qualcosa di locale dentro la funzione, devi distruggerla prima dell'uscita...

Il problema è proprio questo! Per quello che ricordo (dal Visual Basic) era possibile - prima di uscire - "chiudere" un ciclo For...Next assegnando alla variabile il valore finale del For.
Con Lazarus questo non si può fare (a meno che mi sia sfuggito qualcosa) perché impedisce di alterare il valore della variabile responsabile del ciclo.
Per non annoiare, credo cle lo screenshot chiarisca il concetto. La routine è la quarta parte di una funzione suddivisa in sei blocchi (che funziona perfettamente!).
Ovviamente la cancellazione di EsaminaCarattereStringa:=Lenght(Stringa)  non interrompe il programma, però quell'Exit (IMHO) rimane "appeso". Che succede se la funzione viene richiamata un numero eccessivo di volte?
 

Codice: [Seleziona]

 Begin
           ContaVirgole:=0;
           For EsaminaCarattereStringa :=1 to Length(Stringa) do
             Begin
                  CarattereSottoEsame:= Copy(Stringa,EsaminaCarattereStringa,1);
                 If CarattereSottoEsame ='+' then // Verifica presenza superflua del segno +
                   Begin
                        Verifica_Input_Numerico:= Operatore + ': Segno + inutile: eliminare!';
                        Exit;
                   end
                 else
                       If CarattereSottoEsame = ',' Then
                       Begin
                          ContaVirgole:= ContaVirgole +1;
                       end;
                 If ContaVirgole > 1 then
                 Begin
                   Verifica_Input_Numerico:= Operatore + ': Troppe virgole!';
                   Exit;
                 End
                 Else
             End;
           End;                 

[bonmario]

Ci sono varie scappatoie al problema che stai evidenziando.
La prima che mi viene in mente è:
- Prima del ciclo, assegni ad una variabile "pippo" il valore 0 (visto che poi il ciclo parte da 1)
- prima di fare la exit, invece di mettere il valore in "EsaminaCarattereStringa", lo metti in "pippo"

Siccome subito dopo fai la exit, a quel punto esci dalla funzione e torni a "chi l'ha chiamata". Lì, se pippo <> 0, significa che hai fatto la exit, e quello è il valore da considerare, in caso contrario sarà "EsaminaCarattereStringa".

Ciao, Mario

[nomorelogic]

vorrei ricordare l'uso di try...finally

l'istruzione exit fa saltare l'esecuzione al blocco delle istruzioni dopo la finally
utilizzando questo modo, non bisogna preoccuparsi del fatto che la exit possa lasciare in uso delle risorse
io lo uso spesso ed è sicuro

esempio:

Codice: [Seleziona]

function TestPariPositivo(const AValue: integer): boolean;
var sl: TStringList;
begin
   result:=false;
   // alloca risorse
   sl:=TStringList.Create;
   try
     // si esce, destinazione... finally
     if AValue <= 0 then
        exit;

     // elaborazione
     result := (AValue mod 2) = 0;

     sl.Add('Numero inserito');
     sl.Add(AValue.ToString);
     sl.Add(result.ToString);
     ShowMessage(sl.Text);

   finally
     // libera risorse
     sl.Free;
   end;
end;

[DragoRosso]

Rispolveriamo qualche concetto fondamentale.

Tutti i tipi "primitivi", ossia variabili numeriche, booleane, record che contengono solo questi tipi vengono automaticamente "deallocati" dal compilatore (qui ci sarebbe da introdurre anche il concetto di "vita" della variabile). Anche le string, nonostante non siano tipi primitivi seguono questo concetto.

Quindi se dichiari o usi una variabile di quel tipo non devi preoccuparti di nulla.

Tutti i tipi invece managed o complessi come array, puntatori, classi, oggetti, etc ... invece devono essere istanziati e deistanziati a mano. In particolare fare attenzione ai puntatori (che in Pascal non si dovrebbero usare).

Nel caso della tua funzione, intanto al posto dell'EXIT puoi usare un break che ti fà uscire dal ciclo e quindi dopo l'end del ciclo puoi fare tutto ciò che vuoi.

Poi il fatto che tu esca dal ciclo in un qualsiasi modo non comporta alcunchè. Dentro il ciclo non istanzi niente, quindi in qualsiasi modo tu esca non generi problemi.

Ulteriormente, consiglio di usare la variabile automatica RESULT (non deve essere definita, è predefinita nelle funzioni) come contenitore del risultato invece del nome della funzione, il codice risulta più chiaro e leggibile.

Tieni presente che la variabile di iterazione del FOR deve essere usata dentro il ciclo in lettura e una volta usciti dal ciclo non dovrebbe essere letta per vedere ad esempio quanti cicli sono stati fatti, può essere usata riassegnadole un valore e via così.

Come ti accennava @nomorelogic, ci sono anche altre possibilità. Io, ma parlo esclusivamente per me, uso il TRY solo ed esclusivamente per gestire le eccezioni e non per gestire il flusso (non ho mai usato la finally per anche altre motivazioni).

Ciao

[nomorelogic]

Come ti accennava @nomorelogic, ci sono anche altre possibilità. Io, ma parlo esclusivamente per me, uso il TRY solo ed esclusivamente per gestire le eccezioni e non per gestire il flusso (non ho mai usato la finally per anche altre motivazioni).

io ad esempio uso la try...finally ogni volta che alloco risorse manualmente
da una funzione si può uscire anche per una eccezione, con la try...finally sei sicuro di liberare sempre le risorse
ad esempio, nei servizi (no GUI) è abbastanza vitale