Methoden nun doch für Records?

[Dax]

Zitat von jbg:

Faules Pack. Jetzt haben die mich zum Sysop gemacht so dass ich die QC Reports selbst als Fixed abstempeln darf.

Das is ja mal geil...

[grenzgaenger]

ach sagt mal, taugt die hilfe wieder etwas wie zu D5 oder D6??? in den D20XX war das bislang 'n zimliches armutszeugnis...

PS: wenn du wissen willst, wie das mti den class operators funktioniert, findst du hier 'n paar viedeos von daniel, wie er es für d2006 vorstellt

[grenzgaenger]

Zitat von jbg:

Der C++ Compiler scheint nun auch wieder in die Gänge zu kommen. Die haben da zwar noch einiges zu tun (passiert halt wenn man Jahre lang nichts macht) aber der Compiler macht definitiv Fortschritte, wenn ich ihn mit BCB 6 und C++Builder 2006 vergleiche.

hast recht, es war lang genug stillstand, aber der aktuelle weg zeigt, dass es aufwärts geht D2005, war so ziemlich der tiefpunkt der entwicklung...

werd früherstens von d2006 auf D2008 einsteigen, aber die fehler, welche hier in den thread angemeckert wurden, sollten auch in d2006 beseitigt werden, sonst sind die updates als fehlerbereinigung zu teuer... 'und etwas support kann man ja für 3'€ bis 4'€ schon erwarten....

wenn es so weiter geht, werd ich wohl doch wieder auf COBOL umsteigen müssen, wo 'ne vernünftige produktpflege erfolgt....

[jbg]

Zitat von grenzgaenger:

D2005, war so ziemlich der tiefpunkt der entwicklung...

Du hast wohl noch nie von Delphi 8 gehört. Das wird zwar totgeschwiegen, aber es gab ein Delphi 8. Und Delphi 2005 war im Vergleich zu Delphi 8 ein Segen.

Zitat:

werd früherstens von d2006 auf D2008 einsteigen, aber die fehler, welche hier in den thread angemeckert wurden, sollten auch in d2006 beseitigt werden, sonst sind die updates als fehlerbereinigung zu teuer... 'und etwas support kann man ja für 3'€ bis 4'€ schon erwarten....

Seit Delphi 8 war alles mehr oder wendig nur ein kostenpflichtiges Update. Auf Delphi Tiburón (2008) bin ich auch mal gespannt. Endlich Unicode und Generics für Win32, und die VCL soll auch angeblich aktualisiert werden, was wahrscheinlich nur ein paar neue Klassen bedeutet. Denn dass die VCL mal mit Interfaces arbeitet (vor allem TDataSet) wird wohl nie passieren.

[grenzgaenger]

Zitat von alzaimar:

Das kompiliert auch unter BDS2006.

dieses konstrukt wurde unter D2006 erstmals eingeführt.

FYI

[efknarf]

Hallo,

nachdem ich nun testweise ein Project von mir mit diesen Records ausgestattet habe, bin ich zu folgendem Schluß gekommen:
1. Viele Objecte ließen sich komplett ersetzen ohne daß die Lauffähigkeit des Programmes gestört oder mehr Speicher gebraucht wurde. Try-except- bzw. try-finally-Blöcke entfielen auch zu einem Großteil und die Verwaltung wurde einfacher, was zu einer kompakteren Unit führte. Auf diese Weise deklarierte Enumeratoren beschleunigten den Zugriff auf die zugehörigen Daten enorm. Danke für den Tipp.

2. Unbeabsichtigte Veränderung eines Datenrecords kann zwar wirkungsvoll behindert, aber nicht verhindert werden. Bei einer Deklaration eines Typs nach folgendem Rezept:

Delphi-Quellcode:

unit  unit1

interface

type
  TTest = Record
  private
    FItem1:  Integer;
    FItem2:  Integer;
  public
    Item1: Integer read FItem1;
    Item2: Integer read FItem2;
  end;
  
  TWriteTest = Record
  private
    FTest:  TTest;
  public
    property Item1: Integer read FTest.FItem1 write FTest.FItem1;  
    property Item2: Integer read FTest.FItem2 write FTest.FItem2;
  end;

Delphi-Quellcode:

unit  unit2

interface

uses
  Unit1;

type
  TNewTest = type Unit1.TTest;

implementation

procedure TueDies(var T: TNewTest);
begin
  T.FItem1:=25;   //hier wird bei FItem1 eine Fehlerlinie angezeigt
  // T.Item:=25     ist nicht möglich und erzeugt eine Fehlermeldung
end;

(* Diese Art der Datenmanipulation funktioniert, sollte aber nicht verwendet werden *)
procedure SetData(var T: TTest; Item1,Item2: Integer);
var Temp:  TNewTest absolute T;   //Temp belegt den selben Adressbereich wie T;
begin
  Temp.FItem1:=Item1;  //rote Linie unter FItem1  
  Temp.FItem2:=Item2;  //rote Linie unter FItem2
end;

stehen nun in den in Unit2 deklarierten Prozeduren auch alle als Privat deklarierten Felder und Methoden zur Verfügung, die den neuen Datentyp verwenden. Der Editor von Delphi unterstreicht diese Felder zwar mit einer roten Linie, aber den Compiler interessiert das nicht. Über ein Typecasting kann nun auch der ursprüngliche Record verändert werden. Allerdings entspricht das nicht einem sauberen Programmierstil und ich rate deshalb dringend davon ab, in Hinblick darauf, daß in späteren Versionen von Delphi dieser Bug - ist das einer? - beseitigt werden könnte. Für diesen Zweck sollte man den Recordtyp Unit1.TWriteTest verwenden.

3. Prozedurale Zeiger (Methodenzeiger bzw. Prozedurzeiger) auf die "Methoden?" eines Records konnte ich nicht erstellen, ohne einen internen Fehler auszulösen und mein Delphi zum Absturz zu bringen. Eigentlich ja auch logisch, da Records ja keine Objecte sind (im eigentlichen Sinne) und demzufolge eigentlich auch keine Methoden haben können.

4. Die Lesbarkeit und die Wartung wird einfacher, da die meisten manipulativen Prozeduren und Funktionen nun in diesem Record gekapselt werden können.

5. Beim Aufruf der Programmierhilfe im Editor von Delphi (ich meine die ListBox, in welcher man die Prozeduren und Eigenschaften von Objecten auflisten ud auswählen kann), listet nicht mehr hunderte Eigenschaften und Methoden auf, die kein Mensch braucht, sondern nur diese, die in diesem Record gekapselt sind.

6. Dennoch sollte man die Warnungen, welche hier von den verschiedenen Usern gegeben wurden nicht unbeachtet lassen, wenn man solche Records verwendet. Wer abwärts-kompatibel bleiben muß, der darf natürlich diese Records nicht verwenden. Für alle Anderen, die diese Art der Deklaration noch nicht kennen, empfehle ich, diese Records einfach mal auszuprobieren.
Auch nicht unbeachtet lassen darf man die zusätzliche Stackbelastung durch solche Records, da sie meistens als lokale Variablen in Prozeduren Verwendung finden und in diesem Falle nicht auf dem Heap abgelegt werden.

7. Ein als const-Parameter übergebener Record kann trotzdem über seine manipulativen Methoden verändert werden. Also Vorsicht, wenn ein solcher Record in einem Object Verwendung findet und keine Vorkehrungen für versehentliches Ändern getroffen sind. In diesem Falle nämlich bekommt das Besitzer-Object von dieser Veränderung nichts mit.

Ich für meinen Teil, und das ist nur meine persönliche Meinung und Bedarf keiner weiteren Kommentare, finde diese Art der Record-Deklaration einfach Spitze. Da mir Delphi2006 nicht zur Verfügung steht, war es für mich nicht möglich, dieses Konstrukt schon eher auszuprobieren. In meiner Version funktionierte es einwandfrei, bis auf den Prozeduralen-Zeiger-Crash. Aber vlt. hat ja jemand eine Idee, wie man dieses Problem umgehen kann.

Bye

und ein schönes Wochenende an alle.

Frank