Function mit mehreren Rückgabewerten

[freimatz]

Zitat von himitsu:

* oder ...

Im Result ein Datentransfer-Objekt

Zitat von Elvis:

Gibt es eigentlich irgendeinen speziellen Grund, warum es hier normal zu sein scheint, reine Ausgabeparameter als "var" anstatt als "out" zu deklarieren?

das out wurde erst später in Delphi implementiert. Also ich vermute eines dieser drei: Gewohnheit, Faulheit und/oder Ignoranz.

Zitat von Elvis:

Soll der Aufrufende nicht sehen können, dass er da gar nix reinpacken muss?

Ich meine Ja.
Ich selber verwende aber weder var noch out, sonder benutze wie hier schon angesprochen immer Funktionen.

[himitsu]

Und z.B. ein String, Variant, DynArray und Interface sind gemanagte Typen, wo die Variable "initialisiert" sein muß, da Delphi den Speicher automatisch verwaltet.

Solche Typen passen da nicht zur Philosophie des OUT und OUT würde (eigentlich) das Speichermanagement schrotten.


Für sowas nutze ich dann einfach Attribute oder Kommentare, als "Dokumentation".

Delphi-Quellcode:

procedure GibMir([out] Variable: string);

procedure GibMir({out} Variable: string);

/// <summary> gibt mir eine Variable </summary>
/// <param name="Variable"> [OUT] hier rein </param>
procedure GibMir(Variable: string);

[Hobbycoder]

Man könnte auch für die Rückgabe eine Klasse oder einen Record nutzen, wenn man keine VAR oder OUT in den Parametern nutzen will.

Delphi-Quellcode:

type
  TBackData=class
    a: Integer;
    b: Integer;
    c: Integer;
  end;

function berechneirgendwas(x, y: Integer): TBackData;
begin
  Result:=TBackData.Create;
  Result.a:=x*y;
  Result.b:=x+y;
  Result.c:=x-y;
end;

procedure irgendwo;
var
  backdata: TBackData;
begin
  backdata:=berechneirgendwas(10, 5);
  try
    // mach irgendwas mit den Daten
  finally
    backdata.free;
  end;
end;

[Dennis07]

Wäre natürlich schön, wenn Delphi nativ Tupel unterstützen würde. Python kann das sehr schön:

Code:

def give_two:
  return 1, 2

one, two = give_two()

In Delphi gibt es da nur drei möglichkeiten:

1. Du gibst ein Array oder IEnumerable-Objekt zurück
2. Du deklarierst die einen Record und gibst ihn zurück
3. Du verwendest out- (oder var-) Parameter

[freimatz]

Zitat von Dennis07:

... nur drei ...

Nein.

[Dennis07]

Zitat von freimatz:

Nein.

Bitte nicht so ausführliche Kommentare schreiben, mein Gehirn kann die nicht verarbeiten.

Zitat von Rollo62:

Delphi-Quellcode:

procedure GibMir( AInput, AOutput: string);
begin
    AOutput := AInput + '...';
end;

Du meinstest wohl out AOutput: string . Denn so macht der nen Copy-on-call und behält den zugewiesenen Wert in der Funktion. Du kannst das nur weglassen, wenn der Parameter ein Zeigertyp ist und du den Referenzwert veränderst.

[Rollo62]

Zitat von Dennis07:

Du meinstest wohl out AOutput: string .

Ja klar ...

[Sinspin]

Zitat von Dennis07:

Wäre natürlich schön, wenn Delphi nativ Tupel unterstützen würde. Python kann das sehr schön:

Code:

def give_two:
  return 1, 2

one, two = give_two()

In Delphi gibt es da nur drei möglichkeiten:

1. Du gibst ein Array oder IEnumerable-Objekt zurück
2. Du deklarierst die einen Record und gibst ihn zurück
3. Du verwendest out- (oder var-) Parameter

Wärend die Schlange nur zischt, hat das Orakel Antworten.

Ich finde Python hier unscharf und unklar.
Die Optionen die Delphi einem gibt bedeuten mehr Schreibaufwand aber auch deutlich bessere Lesbarkeit.
Gerade durch die Rückgabe oder Verwendung eines Interfaced Objektes bekommt man unendliche Freiheit. Und, das sogar ohne sich auf die Anzahl der Parameter festlegen zu müssen.
Natürlich kann sowas in Speicherverschwendung ausarten. Jede Münze hat halt zwei Seiten.

[Stevie]

Tuple unpacking ist ein ziemlich klares und verständliches Konzept.

Was an dem Code oben etwas ungewohnt ist, ist die Typinferenz bei der give_two Funktion.
Aber wenn man klareren Code schreiben will, dann kann man auch Type Hints (seit Python 3.9) und den Tuple Konstructor explizit nutzen:

Code:

def give_two() -> tuple[int,int]:
  return (1, 2)

[jaenicke]

Zitat von Stevie:

Tuple unpacking ist ein ziemlich klares und verständliches Konzept.

Verständlich ist es schon, aber wie in Delphi bei Methoden mit vielen Parametern unübersichtlich. Da finde ich benannte Argumente in C# deutlich besser. Entsprechend finde ich es auch besser, wenn man einen Record oder ähnliches zurückbekommt, so dass man mit Namen auf die Werte zugreift und nicht z.B. über Tupel basierend auf der Reihenfolge.