Delphi-PRAXiS
Seite 3 von 4     123 4      

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Tutorials und Kurse (https://www.delphipraxis.net/36-tutorials-und-kurse/)
-   -   Delphi Kurzreferenz (https://www.delphipraxis.net/156897-delphi-kurzreferenz.html)

gammatester 5. Jan 2011 21:53

AW: Delphi Kurzreferenz
 
Zitat:

Zitat von himitsu (Beitrag 1072495)
leider wurde schon seit ewigen Zeiten und immernoch in XE ein bissl was vergessen.
Delphi-Quellcode:
var
  a, b: array of Byte;

a := (1, 2, 3, 4, 5);
b := a;
b[3] := 888;
// a := (1, 2, 888, 4, 5)
// b := (1, 2, 888, 4, 5)
beim Schreibzugriff sollte ja, sobald mehrere Referenzen auf die selben Array-Daten zeigen, das zu beschreibende Array kopiert werden, bevor der Schreibzugriff startet.

PS: String entspricht einem quasi einem aufgemotzten array of Char

Jetzt mußt Du nu nur noch verraten, wie Du 888 in ein Byte unterbringen kannst, und es offensichtlich wieder auslesen kannst! Oder hast Du etwas geschummelt ohne nachzudenken?

MrSpock 5. Jan 2011 21:57

AW: Delphi Kurzreferenz
 
Zitat:

Zitat von Luckie (Beitrag 1072480)
Zitat:

Zitat von MrSpock (Beitrag 1072462)
Hallo Luckie,

was ich mir häufig nicht merken kann (und deshalb in einer Kurzreferenz gerne enthalten sehen würde) ist die Frage, ob über eine einfache Zuweisung Strukturen kopiert werden oder ggf. nur eine Referenz. (Arrays, Records, Objekte, etc.)

Könntest du mal bitte ein Beispiel machen?

Ja:

Delphi-Quellcode:
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?
Das wären jetzt ein paar Beispiele.

Luckie 6. Jan 2011 02:24

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?

pertzschc 6. Jan 2011 07:55

AW: Delphi Kurzreferenz
 
Zitat:

Zitat von Luckie (Beitrag 1072515)
Heute, 03:24 by Luckie

Was machst Du so in der Nacht??? Auch mal schlafen?

Deep-Sea 6. Jan 2011 08:45

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.

Luckie 6. Jan 2011 16:21

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.

sx2008 6. Jan 2011 16:50

AW: Delphi Kurzreferenz
 
Zitat:

Zitat von Deep-Sea (Beitrag 1072524)
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

Wenn man im Konstruktor das inherited nicht aufruft, dann wird keiner der ererbten Konstruktoren aufgerufen.
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:

Zitat von Deep-Sea (Beitrag 1072524)
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.

Nach dem Aufruf von inherited ist das Objekt freigegeben, jeder Zugriff auf ein Feld des Objekt ist also ein Zugriff auf ungültigen Speicher.
Oftmals bleibt der Zugriff auf den freigegebenen Speicher folgenlos, aber man hat eine tickende Zeitbombe im Sourcecode!
Delphi-Quellcode:
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;
Also ich kenne kein Szenario in dem es nötig wäre nach den Aufruf von inherited noch etwas anderes zu tun.

Deep-Sea 6. Jan 2011 17:07

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:
constructor TStringStream.Create;
begin
  Create('', TEncoding.Default, False);
end;
Solche Konstrukte gibt es zu tausenden. Es zu einem Dogma zu machen, dass in einem Konstruktor inherited vorkommen muss, ist somit einfach nicht richtig.

Beispiel, wo der geerbte Konstruktor und Destruktor nicht in der dogmatisch genannten Reihenfolge aufgerufen werden:
Delphi-Quellcode:
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;
Ich kenne auch niemanden, der jüdischen Glaubens wäre. Und trotzdem gibt es Juden :roll:

p80286 6. Jan 2011 17:27

AW: Delphi Kurzreferenz
 
Zitat:

Zitat von Deep-Sea (Beitrag 1072691)
Delphi-Quellcode:
constructor TStringStream.Create;
begin
  Create('', TEncoding.Default, False);
end;
Solche Konstrukte gibt es zu tausenden.

Darum müssen sie ja noch längst nicht richtig sein.
Auf den ersten Blick frage ich mich "wo ist das Create was hier aufgerufen wird".

Zitat:

Zitat von Deep-Sea (Beitrag 1072691)
Es zu einem Dogma zu machen, dass in einem Konstruktor inherited vorkommen muss, ist somit einfach nicht richtig.

Aber vielleicht zur Regel? Und da kann es Ausnahmen geben.
(zumindestens in TObject.Create sollte es kein inherited geben)

Zitat:

Zitat von Deep-Sea (Beitrag 1072691)
Ich kenne auch niemanden, der jüdischen Glaubens wäre. Und trotzdem gibt es Juden :roll:

Eben. Aber Deine Aussagen könnten leicht so interpretiert werden, als wäre die halbe Bevölkerung jüdischen Glaubens, und das ist glaube ich, nicht richtig.

Gruß
K-H

Deep-Sea 6. Jan 2011 18:01

AW: Delphi Kurzreferenz
 
Zitat:

Zitat von p80286 (Beitrag 1072694)
Darum müssen sie ja noch längst nicht richtig sein.

Sind sie aber. Richtig, weit verbreitet und nicht mal schlechter Programmierstil.

Zitat:

Zitat von p80286 (Beitrag 1072694)
Auf den ersten Blick frage ich mich "wo ist das Create was hier aufgerufen wird".

Schau doch in deine eigene Classes.pas?! Klar wird in dem aufgerufenen Konstruktor inherited aufgerufen. Aber zum 3. mal: Es muss somit nicht in jeden! In jedem 2. Thread im Forum wird gesagt, dass die Fragesteller nicht einfach Copy-und-Paste nutzen sollen, sondern den Code verstehen sollten. Wie kann man dann hier meinen, dass man Anfängern einfach sagt, dass inherited am Anfang eines jeden Konstruktors zu stehen hat, ohne ihm zu erklären warum man das (fälschlicher weise) meint.


Zitat:

Zitat von p80286 (Beitrag 1072694)
Eben. Aber Deine Aussagen könnten leicht so interpretiert werden, als wäre die halbe Bevölkerung jüdischen Glaubens, und das ist glaube ich, nicht richtig.

Dann nimm halt Inder. Davon gibt es ein paar mehr. Erbsenzähler -.-


Alle Zeitangaben in WEZ +1. Es ist jetzt 09:31 Uhr.
Seite 3 von 4     123 4      

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz