Procedure vs Function, Vor- und Nachteile

[KodeZwerg]

Hallo, der Titel ist ja recht Aussagekräftig

Beispiele

Delphi-Quellcode:

// Funktionen Vorteil, sie geben etwas direkt wieder
Function Beispiel : Boolean;
begin
  Result := True;
end;

// Proceduren können ja auch etwas wiedergeben per Var
// Nachteil, man benötigt eben eine Variable um das Var auszuwerten
Procedure Beispiel (var bResult: Boolean);
begin
  bResult := True;
end;

Aber was Unterscheidet die Beiden noch? Gibt es im Speicher Unterschiede? Was ist performanter?
Gibt es Unterschiede wie Delphi es handhabt wenn eine Function/Procedure eingeleitet bzw. am Ende angekommen ist?
Oder wie schauts aus in Libraries (DLL), man kann ja beides EXPORT machen.
Was fällt Euch noch zum Thema Procedure vs Function, Vor- und Nachteile ein?
Ich würde gerne Eure Meinungen dazu erfragen, egal wie verwegen, falls es abstrakte Unterschiede gibt.
Oder Beispiele wo man für eine Sache eher das nehmen sollte wohingegen bei anderen Sachen nur das andere genommen werden sollte mit einer Mini-Begründung.

Falls sich jemand hier einklinkt und Antwortet, Danke dafür!

[Zacherl]

Ziemlich wurscht. Wenn man einen Rückgabewert hat, sind Funktionen zu bevorzugen, da sie intuitiver sind und genau für diesen Zweck entwickelt wurden. In seltenen Fällen (bei Übergabe großer Strukturen bzw. Strings, etc.) kann ein var Parameter sinnvoll sein, um Kopieroperationen zu vermeiden. Muss man sich im Normalfall aber keine Gedanken drüber machen.

Auf Assembler-Ebene gibt es keine signifikanten Unterschiede.

[Redeemer]

Zitat von Zacherl:

Ziemlich wurscht. Wenn man einen Rückgabewert hat, sind Funktionen zu bevorzugen, da sie intuitiver sind und genau für diesen Zweck entwickelt wurden. In seltenen Fällen (bei Übergabe großer Strukturen bzw. Strings, etc.) kann ein var Parameter sinnvoll sein, um Kopieroperationen zu vermeiden. Muss man sich im Normalfall aber keine Gedanken drüber machen.

Da hast du var mit const verwechselt.

Zudem verwechselt ihr beide var mit out .

[KodeZwerg]

Da würde ich gerne nochmal nachhaken

Delphi-Quellcode:

Procedure Beispiel1 (var bResult: Boolean);
begin
  bResult := True;
end;

Procedure Beispiel2 (out bResult: Boolean);
begin
  bResult := True;
end;

Was Unterscheidet Beispiel1 von Beispiel2? Beides schreibt doch bResult um?

[günni0]

Vielleicht hilft das hier
https://www.delphipraxis.net/39878-w...parameter.html

[KodeZwerg]

Zitat:

OUT ist grundsätzlich (per Definition) wie das Funktions-RESULT.
"Wenn" etwas rein geht, dann wird es ignoriert und es wird nur etwas zurückgegeben.
Bzw. der Programmierer darf niemals davon ausgehen, dass dort "gültige" Were von außen rein kommen.

Der Compiler behandelt es allerdings vorallem wie VAR, nur sollte er zumindestens die "Variable nicht initialisiert"-Prüfung deaktivieren.

Hat geholfen, Danke!

edit

Zitat von Zacherl:

Auf Assembler-Ebene gibt es keine signifikanten Unterschiede.

Dafür auch Danke!

[Zacherl]

Zitat von Redeemer:

Zitat von Zacherl:

Ziemlich wurscht. Wenn man einen Rückgabewert hat, sind Funktionen zu bevorzugen, da sie intuitiver sind und genau für diesen Zweck entwickelt wurden. In seltenen Fällen (bei Übergabe großer Strukturen bzw. Strings, etc.) kann ein var Parameter sinnvoll sein, um Kopieroperationen zu vermeiden. Muss man sich im Normalfall aber keine Gedanken drüber machen.

Da hast du var mit const verwechselt.

var ist genau wie (meistens) const ein "pass by reference", also stimmt das schon mit der Vermeidung von unnötigen Kopieroperationen. Da ein Output Parameter ja aber gewünscht ist, macht const hier keinen Sinn

Zitat von Redeemer:

Zudem verwechselt ihr beide var mit out .

Nöö. var ist runtergebrochen auf den generierten Code exakt gleichwertig zu out (auch wenn out gegebenenfalls aus Gründen der Übersichtlichkeit zu bevorzugen ist).

Code:

005CE2D4 E8BFFFFFFF       call Beispiel1 // function
Unit2.pas.48: Beispiel2(X);
005CE2D9 8D45FB           lea eax,[ebp-$05]
005CE2DC E8C7FFFFFF       call Beispiel2 // procedure mit var
Unit2.pas.49: Beispiel3(X);
005CE2E1 8D45FB           lea eax,[ebp-$05]
005CE2E4 E8CFFFFFFF       call Beispiel3 // procedure mit out

Zitat von himitsu:

bei gemanagten Typen ala String, Variant, Interface und dynamischen Arrays macht der Delphi-Compiler aus function Beispiel(...): string; eben auch einprocedure Beispiel(...; var Result: string); und kopiert nichts um

Interessant. So viel "Intelligenz" hätte ich dem Delphi Compiler ernsthaft nicht zugetraut. Wieder was gelernt.

[himitsu]

Prozedur für Füllen von Objekten ala Listen, wo es als Result oft ungünstig ist.

Und Prozedur hat eher Nachteile, denn du brauchst da immer eine "selbstdefinierte" Variable und man kann es nicht direkt weitergeben, z.B. als Parameter an eine andere Prozedur/Funktion oder für's Zusammenrechnen mehrerer Werte ohne Zwischenvariablen.

[himitsu]

VAR und OUT ist praktisch das Gleiche, außer dass bei OUT per Definition kein Eingabewert existiert, also die Variable initialisiert werden müsste, aber für Typen ala String/Array/Interface bricht der Compiler dieses, da sonst die ordnungsgemäße Speicherverwaltung nicht mehr garantiert werden kann.

[himitsu]

Zitat von Zacherl:

In seltenen Fällen (bei Übergabe großer Strukturen bzw. Strings, etc.) kann ein var Parameter sinnvoll sein, um Kopieroperationen zu vermeiden. Muss man sich im Normalfall aber keine Gedanken drüber machen.

Gerade da ist es total wurscht,
denn bei gemanagten Typen ala String, Variant, Interface und dynamischen Arrays macht der Delphi-Compiler aus function Beispiel(...): string; eben auch einprocedure Beispiel(...; var Result: string); und kopiert nichts um.

Leider ist das auch das Problem/die Urache, dass bei Funktionen für das Result keine "wurde nicht initialisiert"-Meldung vom Compiler kommt, da es eben doch initialisiert wurde (außerhalb)
und mit dem Ergebnis, dass bei vergessenen Initialisierung schnell etwas Komisches heraus kommt,

Delphi-Quellcode:

function Test: string;
begin
  Result := Result + 'a';
end;

for i := 1 to 5 do
  S := Test;
ShowMessage(S);  // 'aaaaa'

aber wenn man sich das jetzt gedanklich als Prozedur ansieht, dann ist sofort klar, warum es so ist.