Procedure vs Function, Vor- und Nachteile

[bernau]

Zitat:

Zitat von Zacherl (Beitrag 1399388)

Zitat:

Zitat von bernau (Beitrag 1399387)

Was übrigens irgendwann einen Stackoverflow nach sich zieht, wenn "Test" nur oft genug ausgeführt wird.

Nee, das nicht. Strings werden in Delphi Heap-allocated.

Hast recht. Trotzdem bekommst du dann irgendwann eine Fehlermeldung, dass kein Speicherplatz mehr zur Verfügung steht.

[himitsu]

Das Problem ist ja, dass hier nun oft kein eigtändiger Compiler mehr zum Einsatz kommt und (bald) alles über LLVM geschleift wird.

Im Prinzip müsste "nur" für diese Vaiable der "würde initialisiert"-Status zurückgesetzt werden und schon käme diese Meldung.
Und nebenbei wird das Kompilieren merklich langsamer, als früher das Eigene.

[freimatz]

Zur Ausgangsfrage:
Bei uns verwenden wir wenn immer möglich functions gegenüber out-Parameter (var sind noch outer ;-))
Der hauptaspekt ist dass der code leichter lesbar wird. Bei den Parametern sieht man es beim Aufruf nicht an, dass hier WErte rausgegeben werden, bei einer function ist das klar. Außerdem lassen sich auch Eigenschaften verwenden.

[Zacherl]

Zitat:

Zitat von himitsu (Beitrag 1399390)

Das Problem ist ja, dass hier nun oft kein eigtändiger Compiler mehr zum Einsatz kommt und (bald) alles über LLVM geschleift wird.

Auch die Win32/64 Kompilate? Das wäre wunderbar. Ich bin sicher LLVM schafft solche Optimierungen auch ohne ungewollte Nebeneffekte umzusetzen.

[mkinzler]

Der Compiler ist weiter eigenständig. Nur die Codegenerierung ( vom LLVM-Bitcode) wird über eine angepasste Version von LLVM erledigt. Selbst der C-Compiler ist kein Original-CLang

[Zacherl]

Zitat:

Zitat von mkinzler (Beitrag 1399393)

Der Compiler ist weiter eigenständig. Nur die Codegenerierung ( vom LLVM-Bitcode) wird über eine angepasste Version von LLVM erledigt. Selbst der C-Compiler ist kein Original-CLang

Jap schon klar :) Das ist aber mehr als ausreichend, weil die Optimierungen ja trotzdem schon dem Intermediate Layer durch LLVM ausgeführt werden sollten. Wenn die Übersetzung nach X86 dann nicht absolut versaut wird, sollten wir deutlich bessere Kompilate bekommen. Cool auf jeden Fall.

[himitsu]

In LLVM ist es wohl nur nicht möglich für diese "speziellen" VAR-Parameter (Result) den "Variable wurde initialisiert"-Status auf nein zu setzen, zu beginn einer jeden Funktion, welche hier im LLVM ja schon eine Prozedur ist.
Klang jedenfalls so, als ich schonmal sowas vorgeschlagen hatte.

Ohne LLVM im eigenen Code wäre sowas bestimmt problemloser machbar gewesen.

Ob dann nun irgendwann der "Bug" an sich behoben würde, wobei er per se ja nicht unbedingt ein Bug ist, wäre dann egal, wenn hier wenigstens die Compilerwarnung kommen würde.

[Dennis07]

Wie schon richtig gesagt wurde, ist "var" mit "out" identisch.
Und beide sind wiederrum mit "const" funktionsweise identisch: Alles eine referenzbasierte Übergabe, im Grunde gleichbedeutend mit einem Zeiger. Lediglich "const" hat die besonderheit, dass der Compiler dem Programmierer den direkten Zugriff auf die Variable verbietet. Das lässt sich aber auch über ASM umgehen, wenn man es braucht (was nie der Fall sein sollte!). Auch werden "const"-Parameter bei String-Typen ein wenig optimiert (steht so zumindest im DocWiki), ansonsten verhält es sich aber intern exakt wie mit "var" oder "out".
Wer sich ebenfalls etwas mit ASM in Delphi auskennt, der weiß, dass das Ergebnis, genau wie der erste Parameter einer Funktion, bei 32-Bit immer im EAX-Register übergeben bzw. zurückgegeben wird. Strings und Records werden außerdem IMMER als Referenz übergeben. Insofern ist es völlig belanglos, welche dieser Routinen man benutzt, der Code ist in jedem Fall identisch:

procedure Foo(var X: Integer);

procedure Foo(out X: Integer);

procedure Foo(X: PInteger);

function Foo(const X: Integer): PInteger;

[Zacherl]

Zitat:

Zitat von Dennis07 (Beitrag 1399396)

Strings und Records werden außerdem IMMER als Referenz übergeben. Insofern ist es völlig belanglos, welche dieser Routinen man benutzt, der Code ist in jedem Fall identisch:

Hier muss man schon aufpassen. Im Falle eines nicht-

Delphi-Quellcode:

const/var/out

Strings wird keine direkte Referenz übergeben, sondern lokal ein neuer mutable String erzeugt. Ansonsten würde man ja die übergebene Instanz modifizieren können - was definitiv unerwünscht ist. Auch im Falle von Record stimmt es NICHT, dass immer Referenzen übergeben werden. Das hängt mitunter z.B. von der Record-Größe ab. Selbst ein

Delphi-Quellcode:

const

garantiert hier nicht zu 100% Referenzen! Musste ich selbst noch die Tage nachlesen.

[himitsu]

Zitat:

Zitat von Zacherl (Beitrag 1399397)

sondern lokal ein neuer mutable String erzeugt. Ansonsten würde man ja die übergebene Instanz modifizieren können - was definitiv unerwünscht ist.

Bei WideString stimmt das, da ohne Referenzzählung, aber die LongStrings im Delphi haben eine Referenzzählung.

Referenz wird direkt übergeben (die auf den String und nicht auf die Variable) und verwendet, aber mit RefCount+1 ... beim Schreibzugriff kommt dann ein CopyOnWrite da kein UniqueString.