![]() |
AW: Delphi Kurzreferenz
Zitat:
|
AW: Delphi Kurzreferenz
Zitat:
Delphi-Quellcode:
Das wären jetzt ein paar Beispiele.
type
TMyArray = array[1..5] of Integer; TMyRec = record intVal: Integer; eVal: Extended; end; var a1, a2: TMyArray; rec1, rec2 : TMyRec; ... begin for i := 1 to 5 do a1[i] := i; a2 := a1; // enthält jetzt a2 eine komplette Kopie for a1 oder ist es nur eine Referenez auf a1? a1[3] := 12; // was ist jetzt a2[3] ? rec1.intVal := 4; rec1.eVal := 3.1415; rec2 := rec1; // was enthält jetzt rec2 ? // und wie sieht es bei 2 Objekten derselben Klasse aus? |
AW: Delphi Kurzreferenz
Ui, das müsste ich auch ausprobieren. Wie verhält es sich denn? Und wo kann man das Thema am besten in der Kurzreferenz unterbringen?
|
AW: Delphi Kurzreferenz
Zitat:
|
AW: Delphi Kurzreferenz
@himitsu:
Dafür gibt es ja die Funktion Copy.
Delphi-Quellcode:
b := Copy(a);
Allgemein: Es muss eig. nicht immer inherited aufgerufen werden. Bei Konstruktoren schon gar nicht und bei Destruktoren kann man es weg lassen, wenn man von TObject ableitet :-D Auch dass inherited als letzte Anweisung im Destruktor stehen muss finde ich so nicht richtig. In den meisten Fällen wir dies wohl stimmen, aber es gibt auch Szenarien, wo es so nicht geht. |
AW: Delphi Kurzreferenz
Die Kurzreferenzen noch mal überarbeitet nach Vorschlägen von Dezipaitor. Allerdings alle habe ich nicht noch umgesetzt.
@Dezipaitor: Was das Datum angeht, das ist das ISO-Datumsformat, welches auch offiziell in Deutschland gültig ist. |
AW: Delphi Kurzreferenz
Zitat:
Das kann zu Zugriffsfehlern führen, wenn dadurch z.B. in der Basisklasse eingebettete Objekte nicht angelegt werden. Beim Destruktor kann ein fehlendes inherited zu Speicherlecks und Resourcenverlust führen. Man ist nur dann auf der sicheren Seite wenn man grundsätzlich immer inherited verwendet. Der Name der Basisklasse ist ja ganz leicht von TObject auf eine andere Klasse geändert; wenn man im Konstruktor oder Destruktor schlampig war können leicht (sehr heimtückische) Probleme auftreten. Zitat:
Oftmals bleibt der Zugriff auf den freigegebenen Speicher folgenlos, aber man hat eine tickende Zeitbombe im Sourcecode!
Delphi-Quellcode:
Also ich kenne kein Szenario in dem es nötig wäre nach den Aufruf von inherited noch etwas anderes zu tun.
destructor TKlasseXY.Destroy; // Beispiel für potentiell gefährlichen Code
begin inherited; // Ab diesem Zeitpunkt ist "FHandle" ungültiger Speicher CloseHandle(FHandle); // dieser Aufruf kann zu einer Zugriffsverletzung führen end; |
AW: Delphi Kurzreferenz
War ja klar das meine Worte wieder mal angezweifelt werden und ich als doof abgestempelt werde :stupid:
Beispiel aus der Classes.pas, wo KEIN inherited stehen sollte:
Delphi-Quellcode:
Solche Konstrukte gibt es zu tausenden. Es zu einem Dogma zu machen, dass in einem Konstruktor inherited vorkommen muss, ist somit einfach nicht richtig.
constructor TStringStream.Create;
begin Create('', TEncoding.Default, False); end; Beispiel, wo der geerbte Konstruktor und Destruktor nicht in der dogmatisch genannten Reihenfolge aufgerufen werden:
Delphi-Quellcode:
Ich kenne auch niemanden, der jüdischen Glaubens wäre. Und trotzdem gibt es Juden :roll:
constructor TAbgeleiteteKlasse.Create;
begin FStream := TMemoryStream.Create; inherited Create(FStream); end; destructor TAbgeleiteteKlasse.Destroy; begin inherited; // Könnte ja auf den übergebenen Stream noch zugreifen. FStream.Free; end; |
AW: Delphi Kurzreferenz
Zitat:
Auf den ersten Blick frage ich mich "wo ist das Create was hier aufgerufen wird". Zitat:
(zumindestens in TObject.Create sollte es kein inherited geben) Zitat:
Gruß K-H |
AW: Delphi Kurzreferenz
Zitat:
Zitat:
Zitat:
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 04:03 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz