Unterschied zwischen (var AFileStream: TFileStream) und (AFileStream: TFileStream)

[michele_tedesco]

Hallo zusammen

Irgendwie verstehe ich den Unterschied nicht, wenn ein Stream mit und ohne VAR als Parameter übergeben wird.
Nach meinem Verständnis wird mit VAR die selbe Adresse des Objekts übergeben und ohne VAR nur eine Kopie des Objektes (somit eine andere Adresse) übergeben.

Wenn ich aber im XE5 Debugger die Adresse vergleiche vom Objekt welches OHNE VAR übergeben wird und vom Parameter der aufgeruften Methode, dann sind die Adressen die selbben, auch wenn ich nicht VAR verwendet habe.


Wenn ich den selben Aufruf der Mothode mit VAR im Parameter habe, dann sind die Adressen auch die gleichen.

Was habe ich da missverstanden?

Danke im Voraus!

[Dejan Vu]

Nichts.
Änderungen am Inhalt von 'VAR'-Parametern werden nach außen mitgeteilt. Ohne 'VAR' bleibt die Veränderung des Inhaltes transparent, d.h. nichts geht nach außen.

WIE das vom Compiler umgesetzt wird, ist nebensächlich. Klar, er könnte eine Kopie übergeben, aber wenn in der Routine nie etwas verändert wird, war die Kopie überflüssig. Ergo würde vielleicht ein Referenzzähler, oder ein Lazy-Copy mehr bringen, d.h. es wird die Originaladresse übergeben, aber beim ersten Ändern wird eine Kopie angelegt.

Bei einfachen Datentypen wird bei ohne VAR der Wert direkt übergeben, mit Var die Adresse.

Einfaches Beispiel:

Delphi-Quellcode:

Procedure Foo (Bar : Integer);
Begin
  Bar := Bar + 1;
End;
Procedure FooWithVar (Var Bar : Integer);
Begin
  Bar := Bar + 1;
End;
...
  n := 1;
  Foo(n);  // die '1' wird auf den Stack gepackt, und logischerweise 'n' nicht verändert
  Assert(n = 1);
  FooWithVar(n); // Die Adresse von 'n' wird auf den Stac gepackt und so kann der Inhalt von 'n' verändert werden
  Assert(n = 2);

Und für Objekte gilt: VAR nur dann, wenn die Instanz umgebogen wird.

Delphi-Quellcode:

Procedure ChangeTheStream (Var aStream : TStream);
Begin
  aStream := TMyStream.Create();
End;
...
  // Autschn. Speicherleck.
  theStream := TFileStream.Create...
  ChangeTheStream (theStream);
  Assert (theStream is TMyStream);

Das Problem beim Objekt-Parameter-VAR ist doch: Wer ist hier eigentlich zuständig für das Freigeben? Normalerweise gilt ja: Der, der die Instanz erzeugt, gibt sie auch wieder frei (produziert sauberen Code). Aber hier ist das nicht klar, wer das macht bzw. wer zuständig ist. Ergo: Finger weg, brauchste nicht.

[Sir Rufo]

Hier wird das doch erklärt? :gruebel:
http://docwiki.embarcadero.com/RADSt...meter_(Delphi)

[Dejan Vu]

Ich glaube, eine (halbwegs) ausführliche Antwort ist besser, auch zum Verständiss anderer, die hier nachlesen.
Zudem beantwortet die Erklärung im Wiki die Frage auch nicht:

Zitat:

Die meisten Parameter sind Wert- (Standard) oder Variablenparameter (var). Wertparameter werden als Wert übergeben, Variablenparameter als Referenz.

widerspricht der Beobachtung

Zitat:

Zitat von michele_tedesco (Beitrag 1258621)

...Adresse vergleiche die selben, auch wenn ich nicht VAR verwendet habe

[p80286]

Zitat:

Zitat von Sir Rufo (Beitrag 1258626)

Hier wird das doch erklärt? :gruebel:
http://docwiki.embarcadero.com/RADSt...meter_(Delphi)

Eben nicht, oder besser gesagt nur für die einfachen Typen wie Integer,Boolean usw. Da ist wohl seit TP 3 immer wieder abgeschrieben worden?

Delphi-Quellcode:

procedure Zeigwas(const wert:string ;Lb:Tlabel);
begin
  lb.caption:=wert;  
end;

so bekommt das Label einen neuen Wert, ist ja klar, wenn man sich vor Augen hält, daß hier die Adresse von einem Label übergeben wird und nicht das Label oder eine neue Instanz des Labels.
Ob das alles allerdings so ganz sauber und im Sinne des Erfinders ist:gruebel:

Gruß
K-H

[Sir Rufo]

Es gibt call by value, call by reference und const parameter.

Ein kleiner Test zeigt die Unterschiede

Delphi-Quellcode:

program dp_180328;

{$APPTYPE CONSOLE}
{$R *.res}

uses
  System.SysUtils;

type
  TTest = class
  end;

procedure Output( const AContext : string; AInstance : TTest );
begin
  if Assigned( AInstance )
  then
    Writeln( AContext, ': ', Integer( AInstance ) )
  else
    Writeln( AContext, ': NIL' )

end;

procedure CallByValue( AInstance : TTest );
begin
  AInstance := TTest.Create;
  Output( 'CallByValue', AInstance );
end;

procedure CallByReference( var AInstance : TTest );
begin
  AInstance := TTest.Create;
  Output( 'CallByReference', AInstance );
end;

procedure Call( const AInstance : TTest );
begin
  // Auskommentiert, da es hier einen Compiler-Fehler gibt!
  // AInstance := TTest.Create;
  // Output( 'Call', AInstance );
end;

procedure Main;
var
  LTest : TTest;
begin
  LTest := TTest.Create;
  try
    Output( 'Main', LTest );
    CallByValue( LTest );
    Output( 'Main', LTest );
    CallByReference( LTest );
    Output( 'Main', LTest );
    Call( LTest );
    Output( 'Main', LTest );
  finally
    LTest.Free;
  end;
end;

begin
  try
    Main;
  except
    on E : Exception do
      Writeln( E.ClassName, ': ', E.Message );
  end;
  ReadLn;

end.

Die Ausführung ergibt dann

Code:

Main            : 31925952
CallByValue     : 31925968
Main            : 31925952
CallByReference: 31925984
Main            : 31925984
Main            : 31925984

[himitsu]

Mit dem CONST, VAR und OUT bestimmt man nur, ob der "Inhalt" der Variable verändert werden kann.
Bei einem Integer ist das der Zahlenwert, aber bei einem Objekt ist der nur der interne Instanz-Zeiger.

Ohne VAR kann man keine Andere Instanz eines Objektes zurückgeben, aber der "Inhalt" des Objektes ist davon nicht betroffen.

Prinzipiell wird der "Inhalt" aller Pointer-Objekte nicht beeinflusst.
Außer bei Strings (AnsiString, WideString und UnicodeString, ausgeschlossen den ShortStrings, welche ja wie Records reagieren), denn dort sorgt der Compiler für eine Prüfung und "verbietet" Schreibzugriffe, wenn der Parameter CONST ist und ansonsten sorgt der Compiler dort für die entsprechende Behandlung, indem der Inhalt automatisch "umkopiert" wird, bei einem Schreibzugriff.

[Sir Rufo]

Wenn man weiß was bei einer Instanz übergeben wird (nur eine Referenz, quasi eine Visitenkarte), dann versteht man auch die Delphi-Dokumentation.

Mit dem

Delphi-Quellcode:

var

wird die gleiche Visitenkarte (Referenz) übergeben. Bemale ich die, dann ist die bemalt.

Ohne dem

Delphi-Quellcode:

var

wird eine Kopie der Visitenkarte (Referenz) übergeben. Bemale ich die, dann ist eben diese Kopie bemalt und das Original bleibt unverändert.

Mit dem

Delphi-Quellcode:

const

wird die Visitenkarte (Referenz) als unbemalbares Objekt (Read-Only) übergeben und kann gar nicht bemalt werden.

[OlafSt]

Keiner hat die Frage wirklich verstanden, ergo hat sie auch keiner wirklich beantwortet. Ist übrigens eine Frage, die ich mir vor langer Zeit auch mal stellte und dann einfach beschloß "ist halt so":

Ich nehme einen

Delphi-Quellcode:

TFileStream

und öffne eine Datei.
Nun rufe ich eine Methode auf, und übergebe diesen Stream als Parameter.
In dieser Methode wird nun per

Delphi-Quellcode:

Seek

-Methode des

Delphi-Quellcode:

TFileStreams

an das Ende der Datei gesprungen.

Es ist echt schnurzpiepegal, ob ich den TFileStream als

Delphi-Quellcode:

CONST

,

Delphi-Quellcode:

VAR

oder auch normal übergebe, die Seek-Methode verschiebt den Dateizeiger ans Ende der Datei. Ergo verändere ich doch den

Delphi-Quellcode:

TFileStream

(wenigstens seinen Dateizeiger !), was doch dem

Delphi-Quellcode:

CONST

widerspricht.

Ich habe das irgendwann einfach so akzeptiert, das CONST nicht vollständig auf Objekte wirkt.

[DeddyH]

Du änderst nur Eigenschaften des Streams, aber nicht den Stream (also die übergebene Instanz) selbst. Das wäre aber möglich, wenn man ihn als Var-Parameter übergibt, und kann zu sehr hässlichen Nebenwirkungen führen, wenn man nicht weiß, was man da tut. Ein Negativbeispiel findet sich z.B. hier (unten unter "Vorsicht bei Zeigertypen!").