RTTI-Umfrage/Erfahrungen?

[himitsu]

Moin,

hier geht es jetzt mal nicht um was Wichtiges/Schlimmes.
Ich wollte einfach nur mal soeinen kleinen Überblick erlangen, in wie weit eigentlich die RTTI verwendet wird.

Wer nutzt denn die RTTI?
Vorallem wie oft, in welchem Umfang und wofür eigentlich?
Lieber die Alte, oder doch eher die Neue/Erweiterte? (hier ist, für ältere Delphis, die Antwort schon klar)

Die alte RTTI ist oftmals leichtgewichtiger/flotter und nicht alles der alten RTTI findet sich (genauso einfach) in der neuen erweiterten RTTI.
Die neue RTTI hat mit Multithreading eventuell einige Problemchen (da werden globale Instanzen verwendet), während die Alte meist nur blind direkt auf schreibgeschützten Pointern arbeitet und da praktisch nichts passieren kann.

* Daten/Objekte (de)derialisieren, für Speicherung/übertragung
- über die alte RTTI aus System/TObject/TypInfo, sowie TReader/Writer (das nutzt auch immernoch die VCL) und Teilweise auch im Variant (wobei dort oft auch einfach hart gecastet wird)
- oder nur noch mit der neuen RTTI.pas (TRttiContext)

* Hacking/Bugfixing
- via RTTI
- über doofe Zeiger "blind" zugreifen

* als zusätzliche Informationsquelle, um die Dokumentation zu ergänzen

* als Hilfe zum Debuggen
- TVirtualMethodInterceptor
- Zugriffe und Daten überwachen/auslesen

...




Und nun noch ein kleiner neugieriger Blick in die IDE, den die RTTI lässt sich ja nicht nur im eigenen Programm benutzen.

Da speichert die RTTI standardmäig jede Kleinigkeit, außer da, wo sie doch praktisch wäre. (bei Interfaces, wenn nicht explizit mit {$M+} deklariert)
Von fast 8500 Interfaces besitzen nur 40 ein paar mehr Infos (wie z.B. Name und Deklaration der Methoden), als nur die IID (GUID), Unit der Deklaration und die Anzahl der Methoden.


Aber witzig ist, daß die gesamte RTTI der Delphi XE3 Prof-RTL/VCL/FMX/IDE als Text nur 21 MB groß ist und schlappe 40800 Typen umfasst, davon etwa 17000 Klassen und 8500 Interfaces.
Im RAD Studio XE6 Architekt Trial sind es 23 MB und genau 46000 Typen (inkl. meiner 2 Test-Interfaces), davon 11444 Interfaces ohne und 7 mit Methoden-RTTI. (das Fehlende waren zufällig die MSXML6-Interfaces in einer gewissen DevJET_DI_XE3_Express.dll)


Nja, ein passendes Interface hab ich wenigstens gefunden, für eine geplante IDE-Erweiterung ... jetzt nur noch rausfinden, wie man es genau benutzt, denn es gibt nirgendwo Infos. Google kennt nur 2 Steiten, wo das Interface zufällig in einem Stacktrace auftaucht und die 2 Kommentare der OpenToolsAPI sind eher als spärlich zu bezeichnen. (aber das ist hier erstmal egal)

[mquadrat]

Wir benutzen die neue RTTI für Databinding und die Konfiguration des ORM via Annotations.

[Lemmy]

Hi,

ich habe in einem Projekt mit Delphi 7 die RTTI für Serialisierung/Deserialisierung verwendet um mein Modell zu laden/speichern. Dazu kam dann später noch das Oberflächenbinding, alles unter der alten RTTI.

[himitsu]

Etwas Schönes, das ich vorhin entdeckte, das aber in der OH nicht so recht erwähnt wird.

Wir wissen doch, daß der Default-Wert nur Ordinal sein kein und wenn, dann hätte man sich eine Stored-Prozedur schreiben müssen.
Das stimmt jetzt nicht mehr, denn via entsprechenden Attributen kann man den Default-Wert auch angeben. (hatte schonmal vor das selber zu machen, aber jetzt, mindestens ab XE3, gibt es das nun doch schon)

Wobei die XE3-OH hierfür zwar Einträge besitzt, aber mit dem falschen Inhalt (die Beschreibung von TCustomAttribute).
XE5/XE6 haben hier zwar inzischen die richtigen Einträge, aber wofür die Attribute sind, wird da wohl nicht beschrieben.
Und eigentlich sollte man sowas doch auch beim "default" au mit verlinken.

Zitat von Unit Classes:

Delphi-Quellcode:

  DefaultAttribute = class(TDefaultAttributeBase)
    constructor Create(const DefaultValue: Int64); overload;
    constructor Create(const DefaultValue: String); overload;
    constructor Create(const DefaultValue: Extended); overload;
    ...

  NoDefaultAttribute = class(TDefaultAttributeBase)
    constructor Create;

  StoredAttribute = class(TCustomAttribute)
    constructor Create(const StorageHandlerFlag: Boolean); overload;
    constructor Create(const StorageHandlerName: string); overload;

  ObservableMemberAttribute = class(TCustomAttribute)
    constructor Create(const AMemberName: string); overload;

(ObservableMemberAttribute hat was mit dem DataBinding zu tun)

[himitsu]

http://qc.embarcadero.com/wc/qcmain.aspx?d=46581

[himitsu]

Meine Erfahrung, nach einen grauenvollen Woche, wo ich die Attribute jetzt mal richtig benutzen wollte.

Man kann den Scheißdreck im XE3 total vergessen, denn überall knallt irgendwas, sobald auch nur ein Attribut darin involviert ist.
Der Compiler hat aber nie was auszusetzen ... nur die RTTI-Infos oder die Auslesefunktionen scheinen voll im Arsch zu sein.


Einfache Attrigube mit oder ohne Paarameter ... aus inerklärlichen Gründen funktioniert das hier und da, aber dort plötzlich nicht.
Dann knallt es mit wunderschänen Zugriffsverletzungen, sobald auch nur versucht wird auf GetAttributes zuzugreifen.

Selbst ein RegisterComponents scheint intern irgendwelche Attribute zu prüfen, was ganz nett abraucht, wenn an der Klasse das kleinste Attribut hängt.


Attribute mit mehreren Constructoren kann man auch vergessen, denn da knallt das GetAttribute immer.


[edit]
Ja, man könnte sich natürlich auch die Bugfixes mit dem XE6 kaufen (da scheint es zu gehn), aber eigentlich war der Code für ältere Delphis angedacht.

[Der schöne Günther]

Kraftausdrücke hin oder her, ich bin hier, da es mein einziger Googletreffer zu "Delphi StoredAttribute" ist. Ich verstehe nicht ganz, wozu es gedacht ist. Kannst du es weiter erklären? Die erzählt nur im Fließtext wie die Konstruktor-Parameter heißen. Nicht aber, wofür sie eigentlich gut sind...

[himitsu]

Delphi-Quellcode:

type
  TMyClass = class
    property MyProperty: MyType read ... write ... stored True;
    property MyProperty: MyType read ... write ... stored MyStoredProc;
    property MyProperty: Integer read .. write ... default 123;
    property MyProperty: String read ... write ... default 'abc';  // geht natürlich nicht
    property MyProperty: MyType read ... write ... nodefault;

    [Stored(True)]
    property myproperty: MyType read ... write ...;
    [Stored('MyStoredProc')]
    property myproperty: MyType read ... write ...;
    [Default(123)]
    property myproperty: Integer read .. write ...;
    [Default('abc')]
    property myproperty: String read ... write ...;
    [NoDefault]
    property myproperty: MyType read ... write ...;

    procedure MyStoredProc: Boolean;
  end;

Oben der "alte" Modus und darunter das neue Modus, aber eigentlich ist nur das Default für nicht-ordinale Typen neu, also Int64, Float und String.

Delphi-Quellcode:

type
  [ObservableMember('Text')]
  TObservableEdit = class(TEdit)
    ...
  end;

Das ObservableMember gibt an, daß das Property TEdit.Text für's LifeBinding verwendet wird, bzw. damit definiert man welcher Verbindungpunkt im LifeBinding zur Verfügung steht und wie er heißt.

http://blogs.embarcadero.com/jimtier...12/10/01/31653
http://forums.unigui.com/index.php?/...ed-components/

Für Stored, NoStored und Default kann man also noch in den alten OH-Einträgen nachschlagen.
http://docwiki.embarcadero.com/RADSt.../Eigenschaften
http://docwiki.embarcadero.com/RADSt.../en/Properties

Und ansonsten die OH ist wirklich für den A***** (auf Englisch klingt es auch nicht besser)
http://docwiki.embarcadero.com/Libra...emberAttribute
http://docwiki.embarcadero.com/Libra...tribute.Create

[Der schöne Günther]

Also das ist speziell für DFM-Formulare gedacht? Weil sonst hätte ich erwartet, das bei der JSON-Serialisierung zu sehen. Stattdessen haben sie da schon wieder neue Attribute erfunden.

[himitsu]

Jupp, wird seitens Delphi ausschließlich von TReader und TWriter verwendet.

Wenn du selber eine JSON-Serialisierung bastelst, dann kannst du diese Attribute aber gerne mit verwenden.