Procedure vs Function, Vor- und Nachteile

[günni0]

Zitat:

Delphi-Quellcode:

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

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

Ich stehe gerade etwas auf dem Schlauch. Aber warum wird aaaaa ausgegeben?
Man schreibt S bei jedem Schleifendurchlauf doch neu und pro "Test" wird nur 1x a hinzugefügt.

Sollte das nicht nur "a" angezeigt werden?

[KodeZwerg]

Zitat von günni0:

Zitat:

Delphi-Quellcode:

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

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

Ich stehe gerade etwas auf dem Schlauch. Aber warum wird aaaaa ausgegeben?
Man schreibt S bei jedem Schleifendurchlauf doch neu und pro "Test" wird nur 1x a hinzugefügt.

Sollte das nicht nur "a" angezeigt werden?

Nein, S wird 5x durch function addiert (Result := Result + 'a'

[günni0]

Aber Test() hat doch keinerlei Parameter. Wie kommt diese Prozedur denn an die vorherigen Zuweisungen?

[bernau]

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

Damit würde ich aber schlaflose Nächte haben.

Result ist definitiv nicht initialisiert und besitzt einen Zufallswert, der ggf. dann von dem vorherigen Funktionsaufruf noch zufällig vorhanden ist.

Mag sein, dass das jetzt so funktioniert. Dieses Verhalten ist aber nirgends dokumentiert. (Oder ich habe es noch nicht gesehen.)

Bei einer nächsten Compilerfunktion wird das ggf. ganz anders sein.

[p80286]

Interessantes Beispiel was Himitsu da gepostet hat

Delphi-Quellcode:

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

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

nicht nur, das ich ein seltsames Ergebnis bei einer fehlenden Initialisierung bekomme, nein, mein Virenscanner hat auch einen Trojaner gefunden:

Zitat:

Fuery.A!Cl

Kategorie: Trojaner

Beschreibung: Dieses Programm ist gefährlich. Es führt Befehle eines Angreifers aus.

Empfohlene Aktion: Entfernen Sie diese Software unverzüglich.

Elemente:
file:C:\compiler\borland\delphi7\Projects\Project1 .exe
process:pid:1048,ProcessStart:131683403956390456

Gruß
K-H

[himitsu]

Zitat von p80286:

nein, mein Virenscanner hat auch einen Trojaner gefunden:

Das liegt aber nur sekundär an diesem Code.
Dein altes Delphi 7 und dass zuviele böse Programme in Delphi geschrieben wurden und weil viele Virensignaturen einfach nur Schrott sind.

https://www.virustotal.com/de/ zur Gegenprobe

Und die eigene Software kann man als False-Positive melden, dann wird die Signatur meist recht schnell angepasst.
https://www.microsoft.com/en-us/wdsi/filesubmission

[Amateurprofi]

Zitat von bernau:

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

Damit würde ich aber schlaflose Nächte haben.

Result ist definitiv nicht initialisiert und besitzt einen Zufallswert, der ggf. dann von dem vorherigen Funktionsaufruf noch zufällig vorhanden ist.

Mag sein, dass das jetzt so funktioniert. Dieses Verhalten ist aber nirgends dokumentiert. (Oder ich habe es noch nicht gesehen.)

Bei einer nächsten Compilerfunktion wird das ggf. ganz anders sein.

Doch, Result ist definitiv initialisiert und besitzt keinen Zufallswert.
Bei "Function Test:String;" ist Result ein Zeiger auf eine Stringvariable und da Strings immer initialisiert werden, ist damit auch Result initialisiert.
Im nachstehenden Assembler-Auszug kannst du das schön sehen.
Vor dem Aufruf der Funktion Test wird mit lea eax,[ebp-$04] die Adresse der lokalen Variablen S in EAX gestellt.
Das in [ebp-4] tatsächlich die Variable S gespeichert ist, siehst du 6 Zeilen tiefer, wo S als Parameter für ShowMessage in EAX gestellt wird.
Recht hättest du bei z.B. Function Test:Integer;, da ist Result nicht initialisiert.

C_Main.pas.5152: for I:=1 to 5 do
0060FFF4 BB05000000 mov ebx,$00000005
C_Main.pas.5153: S:=Test;
0060FFF9 8D45FC lea eax,[ebp-$04]
0060FFFC E8B7FFFFFF call Test
C_Main.pas.5152: for I:=1 to 5 do
00610001 4B dec ebx
00610002 75F5 jnz $0060fff9
C_Main.pas.5154: ShowMessage(S);
00610004 8B45FC mov eax,[ebp-$04]
00610007 E8C0A2ECFF call ShowMessage

[Zacherl]

Unintuitiv ist das Verhalten allerdings schon. Bei einer Funktion in Delphi erwarte ich grundsätzlich temporäre R-Values. Andere Sprachen - wie z.b. C++ - erlauben ja auch die Rückgabe von Referenzen, da ist das Verhalten aber einheitlich.

[himitsu]

Zitat:

Doch, Result ist definitiv initialisiert und besitzt keinen Zufallswert.
Bei "Function Test:String;" ist Result ein Zeiger auf eine Stringvariable und da Strings immer initialisiert werden, ist damit auch Result initialisiert.

Bitte meine Beiträge dazu genau lesen.

Ja, es wird initialisiert, aber eben nicht dort, wo man vermuten könnte (zu Beginn der Funktion),
also ist aus Sicht der Funktion dieses Result eben nicht "wirklich" initialisiert, zumindestens nicht unbeding mit 0 (einem Leerstring).

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