Methoden nun doch für Records?

[efknarf]

Hallo, ihr fleißigen User,

folgenden Record habe ich deklariert:

Delphi-Quellcode:

type
  TTest = Record
  private
    Feld1: Integer;
    Feld2: Integer;
  public
    Feld3: Integer;
    procedure Clear;
  end;

implementation

procedure TTest.Clear
begin
  Feld1:=0;
  Feld2:=0;
  Feld3:=0;
end;

Nun kann man diesen TTest-Record wie einen gewöhnlichen Record verwenden, wobei sich die Felder so verhalten, wie man es von ihnen erwartet.
Weiß nicht, ob das nun bei jedem hier funktioniert. Bei mir funktionierte es jedenfalls. Ist das nun eine Methode eines Records oder wie nennt man das nun und ist diese Methode identisch mit einer Object-Methode? In der Hilfe zu Delphi und auch hier habe ich nichts dazu gefunden.
:gruebel: :wiejetzt:

[mkinzler]

Eigentlich wird (ab D10) nur Klassenoperatoren unterstützt.
Welche Delphiversion? .Net?

[WS1976]

Hallo,
ich weiss nicht was du für eine Delphi Version hast, aber bei mir geht das weder mit D7 noch mit D2005.
Ausserdem widerspricht das ganz klar der Object Pascal Grammatik.

Delphi-Quellcode:

type
  TTest = Record
//  private
    Feld1: Integer;
    Feld2: Integer;
//  public
    Feld3: Integer;
//    procedure Clear;
  end;
  TForm1 = class(TForm)
  private
    { Private-Deklarationen }
  public
    { Public-Deklarationen }
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}
//procedure TTest.Clear
//begin
//  Feld1:=0;
//  Feld2:=0;
//  Feld3:=0;
//end;

All die auskommentierten Zeilen sind fehlerhaft! Wobei das bei der Procedure im implementation Teil klar ist.
Ihr fehlt ja die Deklaration!

Grüsse
Rainer

[efknarf]

Guten Morgen,

Ja! Das hatte ich fast erwartet. Meine Delphi-Version ist von CodeGear - Delphi 2007. Liegt wohl an der Version, denn in einer älteren Version funktionierte diese Art der Deklaration nicht.
Trotz dieser Neuerung ist selbst nach intensiver Suche in der Delphi-Hilfe nichts darüber zu finden. Bin auch mehr oder weniger nur zufällig darüber gestolpert.

Gruß Frank

[peschai]

Sorry, aber ich konnte das soeben unter Delphi2007Professional nachstellen!!!
Bis auf ein fehlendes ";". Es lässt sich so komplilieren!.
Faszinierend!! Aber klar ist doch hoffentlich, daß man davon tunlichst die Finger lassen sollte!!!
:???:

[efknarf]

Zitat:

Faszinierend!! Aber klar ist doch hoffentlich, daß man davon tunlichst die Finger lassen sollte!!!

Wahrscheinlich hast du damit sogar recht, aber es ist doch toll zu wissen, was machbar ist, denn es vereinfacht vieles. Aber ein wenig seltsam ist das schon, daß man einem Record "Methoden" zuordnen kann.

Gruß

Frank

[WS1976]

Hallo,

ich sehe überhaupt keinen Grund ein solches Konstrukt einzusetzen.
Was soll das Ganze denn vereinfachen?
Mal ganz davon abgesehen, dass du nie genau weisst was passiert.
(Es sei denn du analysierst das Teil auf Assembler Ebene. Viel Spass dabei.)

Grüsse
Rainer

[Bernhard Geyer]

Zitat:

Zitat von efknarf

Wahrscheinlich hast du damit sogar recht, aber es ist doch toll zu wissen, was machbar ist, denn es vereinfacht vieles. Aber ein wenig seltsam ist das schon, daß man einem Record "Methoden" zuordnen kann.

Da man dieses Feature AFAIK unter .NET 2.0 zwingend benötigte hat man es auch gleich für Win32 verfügbar gemacht.
Und was soll seltsam sein? Alle Features von einem richtigen Objekt sind trotzdem nicht möglich. Schon mal versucht von diesem Record eine ableitung zu machen?

[alzaimar]

Das kompiliert auch unter BDS2006.

Zitat:

Zitat von WS1976

ich sehe überhaupt keinen Grund ein solches Konstrukt einzusetzen.

Leichtgewichtige 'Klassen' und statische 'Objekte', siehe B.Geyer's Anmerkungen.

Zitat:

Zitat von WS1976

Was soll das Ganze denn vereinfachen?

Gute Frage. Die haben das vermutlich für Delphi.NET implementieren müssen und dann gleich für Delphi.Win32 verfügbar gemacht.

Zitat:

Zitat von WS1976

Mal ganz davon abgesehen, dass du nie genau weisst was passiert.

:gruebel: Wieso? Es ist doch ganz klar, was passiert.

Schau mal in der Hilfe unter 'Records (erweiterte)'.

Zitat:

Zitat von Die Delphi OH

Records (erweiterte)
Zusätzlich zu den traditionellen Record-Typen lässt die Delphi-Sprache komplexere und “klassenähnliche” Record-Typen zu. Zu den Feldern können Records Eigenschaften und Methoden (einschließlich Konstruktoren), Klasseneigenschaften, Klassenmethoden, Klassenfelder und verschachtelte Typen haben. Weitere Informationen hierzu finden Sie in der Dokumentation zu Klassen und Objekten. Im Folgenden finden Sie eine Beispiel-Record-Typdefinition mit einigen “klassenähnlichen” Merkmalen.

Delphi-Quellcode:

type
  TMyRecord = record
    type
      TInnerColorType = Integer;
    var
      Red: Integer;
    class var
      Blue: Integer;
    procedure printRed();
    constructor Create(val: Integer);
    property RedProperty: TInnerColorType read Red write Red;
    class property BlueProp: TInnerColorType read Blue write Blue;
end;

constructor TMyRecord.Create(val: Integer);
begin
  Red := val;
end;

procedure TMyRecord.printRed;
begin
  writeln('Red: ', Red);
end;

Obwohl Records nun einige der Merkmale von Klassen besitzen, gibt es wichtige Unterschiede zwischen Klassen und Records.

• Records unterstützen keine Vererbung.
• Records können variante Teile enthalten; Klassen nicht.
• Records sind Wertetypen, daher werden Sie bei der Zuweisung kopiert, per Wert übergeben und dem Stack zugewiesen, wenn sie nicht als global definiert sind oder explizit mit den Funktionen New und Dispose zugewiesen werden. Klassen sind Referenztypen, daher werden Sie bei der Zuweisung nicht kopiert, per Referenz übergeben und dem Heap zugewiesen.
• Records ermöglichen das Überladen von Operatoren auf Win32- und .NET-Plattformen; Klassen ermöglichen das Überladen von Operatoren nur bei .NET.
• Records werden automatisch mit einem Standardkonstruktor ohne Argumente erzeugt, Klassen dagegen müssen explizit erzeugt werden. Weil Records einen argumentlosen Standardkonstruktor haben, muss jeder benutzerdefinierte Record-Konstruktor ein oder mehr Parameter haben.
• Record-Typen können keine Destruktoren haben.
  Virtuelle Methoden (die mit den Schlüsselwörtern virtual, dynamic und message angegeben werden) dürfen in Record-Typen nicht verwendet werden.
  Im Gegensatz zu Klassen können Record-Typen auf der Win32-Plattform keine Schnittstellen implementieren; auf der .NET-Plattform können Records jedoch Schnittstellen implementieren.

[Hawkeye219]

Hallo,

hier ist ein mögliches Einsatzgebiet für Records mit Methoden: Enumerator Records.
Der Artikel zeigt auch, daß Records deutlich weniger Verwaltung erfordern - so wie es alzaimar bereits angesprochen hat.

Gruß Hawkeye

[Muetze1]

Das ist ein neues Feature ab BDS2006 und ich kann von der Nutzung derzeit nur abraten, wenn man die Pascal Quellen jemals im C++Builder nutzen möchte. Leider ist das nicht ausführlich getestet bzw. nur in Delphi getestet worden. Ich wollte es in unserem Projekt nutzen, da es sich gerade zu angeboten hatte, aber leider macht mir die HPP Generierung einen Strich durch die Rechnung (bzw. der Linker fliegt ab). Von daher: überlegt es euch. Wenn ihr dieses Konstrukt nutzt, dann schliesst ihr grundsätzlich erstmal alle C++Builder Nutzer aus (und alle vor D10 bzw. C++Builder 10 grundsätzlich).

Folgendes ist sauer aufgestossen bei der Nutzung: QC: 53956 und QC: 53958 wobei CodeGear noch nicht reagiert hat (vermutlich, da BDS2006 ja nun schon wieder "alt" ist).

Grundproblem scheint aber die Zusammenarbeit der C++ und Delphi Abteilung zu sein. Wie ich schon an QC: 53792 merkte, weil solche grundlegenden Dinge müssten beim Testen auffallen. Am besten aber zu sehen war es in der Diskussion um die falsche Umsetzung der const Parameterklausel in QC: 42782 wo Leo Siefert zugeben musste, nicht so viel von Delphi zu verstehen und gleichzeitig wohl auch keinen der Delphi-Leute über Zeit dazu befragen konnte...

Aber: auch wenn es sich so anhört, ich bin mit CodeGear zufrieden. Es wäre aber vllt. eine schnellere Reaktion bei QC Einträge zu wünschen. Vor allem ist es sehr merklich, dass in älteren Umgebungen gefundene Dinge recht stiefmütterlich behandelt werden, da alle am neuen System sitzen. Die Kunden, welche aber nunmal sich ein Produkt zulegen und damit nun erstmal entwickeln, kaufen sich nicht ständig neue Versionen. Von daher sollte man den Einträgen auch mehr Aufmerksamkeit schenken. Die letzten 4 Einträge von mir sollten höchstwahrscheinlich auch unter BDS2007 auftreten - aber so lange das keiner darunter nachvollzieht, hängt der Punkt ewig. Leider sind es z.T. recht gravierende Dinge, die einem die Entwicklung mit dem erworbenen Borland Produkt deutlich erschweren. Gutes Beispiel: QC: 53792 ich muss nun jedes mal das Kommandline Build Tool anschmeissen, da ich sonst niemals irgendwelche Warnung etc. erhalte. Das ist frustrierend nervig und wahrscheinlich auch schnell behoben.

/EDIT: Sorry, falls es nicht ganz passt - ich bin etwas frustriert, da ich gerade wieder an zwei frischen neuen Bugs des BDS sitze und Beispielcode dafür bilde...

[Phoenix]

Meine Meinung ist einfach, dass es da derzeit etwas an der QS fehlt.

So Sachen wie fehlende Units in der einen oder anderen Sprachversion beim Setup liessen sich eigentlich automatisiert testen.

[jbg]

QC: 53792 Pascal Units in BCB LIB Project does not show any warnings
Ist in RAD Studio 2007 (Up3) behoben. Ich bezweifle, dass es jemals ein weiteres Update für BDS 2006 geben wird.
Ich habe aber beim Kompilieren (auch mit dem Pascal-Projekt) einen anderen DCC32 Bug entdeckt. "lTest := lTest + 44;" wirft keine "not initialized" Warnung. Die tritt erst beim "if lOtherTest = lTest then" auf.

QC: 53956 using HPP struct with methods will result in ILI2119
Ist auch in RAD Studio 2007 (Up3) behoben.


QC: 53958 using a set definition in pascal record including getter/setter let the C++ linker fail
Ist in RAD Studio 2007 (Up3) behoben.

Zitat:

Am besten aber zu sehen war es in der Diskussion um die falsche Umsetzung der const Parameterklausel in QC: 42782 wo Leo Siefert zugeben musste, nicht so viel von Delphi zu verstehen und gleichzeitig wohl auch keinen der Delphi-Leute über Zeit dazu befragen konnte...

Leo Siefert ist kein CodeGear Mitarbeiter. Er ist "nur" ein QualityCentral Sysop.

Zitat:

Vor allem ist es sehr merklich, dass in älteren Umgebungen gefundene Dinge recht stiefmütterlich behandelt werden, da alle am neuen System sitzen.

Stiefmüttlerlich ist wohl noch zu midle gesagt. Es wird gar nichts mehr am Altprogramm gemacht. Oder kam je ein Update für eine ältere Version heraus, wenn die neue Version bereits auf dem Markt war?

[Muetze1]

Schade, wirklich schade. Wir haben uns als Firma für das damalige Produkt entschieden um eine Neuentwicklung zu starten (welche noch im vollen Gange ist) und somit ist es wirklich schlecht, wenn Borland die Produktzyklen so verkürzt, so dass es zu keiner relativ benutzbaren Version kommt. Wir als Firma können uns nicht einfach (zum einen während der Entwicklung) noch einfach mal so (wo die Entwicklung schliesslich noch kein Geld reinbringt sondern nur kostet) die neue Version kaufen, nur weil Borland eine neue auf den Markt wirft. Es ist schön zu hören, dass die Fehler in D2007 behoben sind - aber meint CodeGear wirklich, dass wir uns nun die neue Version kaufen? Wir haben genug Geld ausgegeben und das man auf Wunsch sogar noch extra bezahlt für einen Support für ein paar Jahre der einem in Endeffekt überhaupt nichts bringt, da nichts nachgeliefert wird, ist mehr als bedenklich.

Zitat:

Zitat von jbg

Leo Siefert ist kein CodeGear Mitarbeiter. Er ist "nur" ein QualityCentral Sysop.

Aso, das wusste ich nicht. Es hat aber lange gedauert bis er es nachvollziehen konnte - aber sagt ja selber, dass er von Delphi nicht die Ahnung hat. In so fern auch nicht nachvollziehbar, wenn man einen solchen Aufwand betreiben muss damit es anerkannt wird.

Ich bin mal gespannt, ob die Einträge denn überhaupt mal als gefixt übernommen werden. Es ist eigentlich recht deprimierend die QC zu nutzen. Trägt man mal was ein, schreien alle nach einen Beispiel um es nach zu vollziehen. Macht man sich gleich beim Eintrag die Mühe und baut ein Beispiel schaut es sich keiner an und der Beitrag wird ignoriert. Im Endeffekt sieht man als Nutzer nur eins: deutlicher Mehraufwand der rein gar nichts bringt. Dank in dem Sinne kommt ja noch nicht mal. Die einzige Chance habe ich eigentlich nur im Beta Test, wenn ich die Fehler die ich finde auch in der Beta Version vorfinde bzw. ich sie dort direkt feststelle. Nur dann wird der Eintrag überhaupt noch "genutzt".

Borland kann nur nutzen, wenn die Firma grösser ist und sie somit genügend Rücklagen hat sich immer das neueste Produkt zu kaufen, ansonsten ist man eine lange Zeit damit beschäftigt vorhandene Klippen zu umschiffen.

Ich frage mich sowieso seit ein paar Einträgen in der QC ob es sich überhaupt noch lohnt diesen Aufwand zu treiben. Es bringt im Endeffekt nichts - es kommt ja noch nichtmal zu einer Bewertung der Einträge oder irgend einer anderen Rückmeldung.

In so fern schon mal vielen dank jbg, dann weiss ich zumindest schonmal (wie vermutet), dass die gefundenen Dinger in den nachfolgenden Versionen ebenfalls bestanden und zumindest dort behoben sind. Halt mal eine Rückmeldung...

[jbg]

Zitat:

Zitat von Muetze1

Ich bin mal gespannt, ob die Einträge denn überhaupt mal als gefixt übernommen werden.

Ich kann sehr nachdrücklich sein (deutsche System.pas) und habe einige CodeGear-Email Adressen parat. Ich überlege mir gerade, wen ich damit nerven könnte. :mrgreen: Es sollte wohl nicht viel Arbeit sein den Report als "fixed" zu markieren.

Mir ist schon öfter aufgefallen, dass deren intere Bugtracking System RAID nicht so ganz mit QC zusammenarbeitet. Vor allem Kommentare werden gar nicht von QC in RAID übertragen. So kam auch der in RAD Studio 2007 vorhandene Standard-Context-Menu Bug zustande. Mein Kommentar wurde einfach ignoriert und so kam ein fehlerhafter Bugfix in die VCL, der bis jetzt nur durch einen inoffiziellen binär Patch oder einer Patch-Unit (beide von mir) behoben wird. Bin ja mal gespannt ob CodeGear den Fehler nach über einem Monat doch mal behebt, denn dieser Bug betrifft nicht die Programmierer, sondern die Endanwender was bedeutet, das RAD Studio Update 3 ohne einen dieser Patches nicht einsetzbar ist.

[Bernhard Geyer]

Zitat:

Zitat von jbg

Stiefmüttlerlich ist wohl noch zu midle gesagt. Es wird gar nichts mehr am Altprogramm gemacht. Oder kam je ein Update für eine ältere Version heraus, wenn die neue Version bereits auf dem Markt war?

AFAIK wurden bei D6 noch fixes geliefert (nicht als komplettes Exe) als schon D7 auf dem Markt war. Und der letzte BDS-Update war auch nachdem schon Delphi 2006 auf dem Markt war.

Aber gut das man die Sourcen hat. Kann man schön selbst fixen. Hab bei Delphi 6 schon 6 Borland-Units als fix-Version rumliegen. Da wir auch kein Runtime-Packages verwenden ist das auch kein Problem.

[Phoenix]

Tja, dann müssen wir Andreas halt mal in einen Flieger nach Scotts Valley setzen, der soll die Bugs dann am besten selber fixen. Dann ist das auch schnell erledigt und wir haben direkt nen Ansprechpartner vor Ort :mrgreen:

[Muetze1]

Zitat:

Zitat von Bernhard Geyer

Aber gut das man die Sourcen hat. Kann man schön selbst fixen. Hab bei Delphi 6 schon 6 Borland-Units als fix-Version rumliegen. Da wir auch kein Runtime-Packages verwenden ist das auch kein Problem.

Das hilft nur, wenn es nicht die IDE betrifft (siehe QC: 53792). Da kann ich als Produktkäufer nichts dran ändern und es behindert mich.

Grundlegend (auch wenn ich Thread dadurch ein wenig entführe) kann man sich doch aufregen. Borland hat das D2007 so schnell hinterher geworfen, so dass es nicht wirklich fertig war. Und durch genau das beschriebene Verhalten bezüglich der Updates, vergraulen sie Kunden. Eine Entwicklungsfirma kann es sich eigentlich nicht leisten eine Umgebung einzusetzen, welche einen Lebenszyklus von gerade mal einem Jahr hat. Gerade nach der D2007 Aktion sind viele verprellt worden und auch hier bei uns (gerade nochmal mit dem Projektleiter diskutiert) bestärkt es uns eher noch komplett weg zu gehen und andere Umgebungen einzusetzen. Selbst MS bietet einen definierten Support inklusive Updates für einen (vorher) festgelegten Zeitraum an. Da kann man sich sicher sein, dass es mit dem Kauf der Umgebung auch bis zu 3-4 Jahre Updates gibt und man am Ende diesen Zeitraums ein wirklich gut nutzbares Produkt hat.

Vor der Neuentwicklung haben wir lange diskutiert wodrauf wir aufsetzen und was wir nehmen werden. Heute wissen wir, dass die Entscheidung schlecht war. Es standen noch andere Umgebungen zu Auswahl und mit denen wären wir wohl zukunftsicherer gefahren. Es ist wirklich schade, aber ich verstehe auch nicht, wo bei CodeGear in Sachen IDE die Hauptaugenmerke liegen. Immer wieder neue Produkte um neue Kunden zu locken? Alle Altkunden werden verprellt - oder haben genug Geld um ständig auf die neusten Produkte zu updaten. Es ist wirklich enttäuschend.

/EDIT: Wenn ich mir so die Updatepreise auf das RAD 2007 anschaue (wo die Bugs ja behoben sind), dann frage ich mich doch, ob das nicht ein Scherz sein soll. Der Preis ist fast der Preis, den wir für BDS2006 bezahlt haben vor rund einm Jahr (noch nicht mal) und nun sollen wir nochmal soviel Geld ausgeben um eine nutzbare IDE zu bekommen? Wie bitte?

/EDIT2: @jbg: Wenn du schon eine e-mail schreibst und du vllt. einen bei CodeGear kennst der dem Deutschen mächtig ist, dann gib ihm doch mal einen Link auf diesen Thread. Vielleicht wäre es mal interessant für CodeGear zu erfahren, wie deren Kunden "zufrieden" sind bzw. wie es rüberkommt. MS hat den Produktsupport für XP nach öffentlichen Druck verlängert. Vielleicht überlegt es sich CodeGear mal den Produktsupport für die grossen IDEs (BDS/RAD) zu verlängern - schliesslich sind es nicht gerade kleine Systeme für kleine Fuzzelprogramme. Also, ich übe hier damit mal offiziell Druck aus *drück*...

[jbg]

Zitat:

Zitat von Muetze1

Vielleicht überlegt es sich CodeGear mal den Produktsupport für die grossen IDEs (BDS/RAD) zu verlängern - schliesslich sind es nicht gerade kleine Systeme für kleine Fuzzelprogramme.

Ich denke, das eigentliche Problem ist, dass sie nach Delphi 7 einen Flop nach dem anderen eingefahren hatten. Mit RAD Studio 2007 scheinen sie sich nun endlich wieder etwas gefangen zu haben (von ein paar Wehwehchen mal abgesehen). Vor allem die Update-Stategie für RAD Stidio 2007 ist interessant. Zuerst wir Delphi 2007 herausgebracht, dann ein Update 1 dafür. Ein paar Monate später folgte C++Builder 2007, der zugleich Update 2 von Delphi 2007 war. Und mit dem Release von RAD Studio 2007 (Delphi.NET 2007) wurde das Update 3 für Delphi 2007 eingeführt was zugleich Update 1 für C++Builder 2007 war. Für Deu/Fra/Jp wurde sogar noch ein kleiner Patch herausgebracht, der die System.pas nachinstallierte. Vielleicht schieben sie nun noch ein Update hinterher, denn der Contextmenü-Bug ist ein Showstopper. Das wären dann insgesamt 4 Updates (was die IDE betrifft).

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.

[jbg]

Zitat:

Wenn du schon eine e-mail schreibst

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

[Dax]

Zitat:

Zitat von jbg

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

:lol: 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:

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:

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:

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