![]() |
Re: Methoden nun doch für Records?
Zitat:
|
Re: Methoden nun doch für Records?
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 ;-) |
Re: Methoden nun doch für Records?
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.... wenn es so weiter geht, werd ich wohl doch wieder auf COBOL umsteigen müssen, wo 'ne vernünftige produktpflege erfolgt.... |
Re: Methoden nun doch für Records?
Zitat:
Zitat:
|
Re: Methoden nun doch für Records?
Zitat:
FYI |
Re: Methoden nun doch für Records?
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:
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.
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; 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 |
Alle Zeitangaben in WEZ +1. Es ist jetzt 11:40 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 by Thomas Breitkreuz