Procedure vs Function, Vor- und Nachteile

[bernau]

Zitat von Amateurprofi:

Doch, Result ist definitiv initialisiert und besitzt keinen Zufallswert.

Mag sein, dass beim ersten Aufruf von "Test" das Result mit "" initialisiert ist.

Wenn Result bei jedem Aufruf von "Test" initialisiert wäre, dann würde als Ergebnis immer "a" herhauskommen. Ist aber nicht so. Es ist immer der Wert des vorherigen Result vorhanden. Was für mich erst mal undefiniert ist.

Da man ja nicht weis, von wo überall "Test" aufgerufen wird, muss man davon ausgehen, dass Result einen string mit dem Buchstaben "a" in zufälliger Länge hat. Was übrigens irgendwann einen Stackoverflow nach sich zieht, wenn "Test" nur oft genug ausgeführt wird.

Zusätzlich kommt hinzu, dass das Verhalten sich mit dem nächsten Compiler ändern kann. Dann wird vielleicht Result bei jedem Aufruf der Funktion auf "" gesetzt. Mann weis ja nie. Es sei denn, dass dieses Verhalten so dokumentiert ist.

[Zacherl]

Zitat von himitsu:

Zitat von Zacherl:

Selbst bei den class operator werden temporäre R-Values verwendet. Wenn man beispielsweise die Addition eines Record überläd, wird ein komplett neuer temporärer Record erstellt und als Ergebnis des Operators zurückgeliefert, welcher dann letztlich der

Was aber eventuell nichts mit diesem Problem zu tun hat,
denn wenn dort dieser Result-Record auch als VAR-Parameter in eine neue leere Variable geht, dann wäre es praktisch das Gleiche.

Damit wollte ich vor allem die Inkonsistenz aufzeigen.

Zitat von bernau:

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.

Zitat von bernau:

Zusätzlich kommt hinzu, dass das Verhalten sich mit dem nächsten Compiler ändern kann. Dann wird vielleicht Result bei jedem Aufruf der Funktion auf "" gesetzt. Mann weis ja nie. Es sei denn, dass dieses Verhalten so dokumentiert ist.

Das ist ein wichtiger Punkt. Bin auch der Meinung, dass zumindest die "nicht initialisiert" Meldung trotzdem angezeigt oder die ganze Optimierung anders umgesetzt werden sollte.

[bernau]

Zitat von Zacherl:

Zitat von bernau:

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.

[Zacherl]

Zitat von himitsu:

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 von 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

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.

[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.