Klassen Wegoptimieren abschalten ?

[moelski]

Moin !

Ich habe ja hier versucht aus einem String eine Klasseninstanz zu erstellen:
http://www.delphipraxis.net/156256-a...-erzeugen.html

Das funktioniert auch. Aber wenn die Klasse in der Anwendung vorher nie für eine Instanz benötigt wird, dann optimiert der Compiler die Klasse weg.

Gibts einen Schalter/Direktive mit dem ich dem Compiler sagen kann "Diese Klasse immer mit in die Anwendung compilieren" ?

[moelski]

Nachtrag:
http://docs.embarcadero.com/products...spart_xml.html

Dort habe ich schon mal nachgesehen. Aber nix passendes gefunden

[himitsu]

Delphi läßt nunmal alles weg, welches nicht verwendet wird und abschalten läßt es sich nicht.

Einzige Lösung: das gewünschte Verwenden.

Also irgendwo den Klassennamen benutzen und alle Methoden aufrufen.
Und wenn es irgendwo in einem IF-Block steckt, welcher nie aufgerufen würde (also so, daß es der Compiler nicht mitgekommt, denn sonnst läßt es es ebenfalls weg ... z.B. if Klassenvariable <> 0, welche aber nirgends gesetzt wird)

[moelski]

Wasn Bullshit

Nuja, muss man dann wohl mit leben

[himitsu]

Joar, war ich damals auch drüber gestolpert, als ich versuchte einige Klassen über DLL-Grenzen hinweg nutzbar zu machen ... ohne BPLs.

Aber standardmäßig gibt es ja keinen Grund, irgendwas einzubinden, welches nicht genutzt wird ... drum wurde dafür wohl auch keine Moglichkeit implementiert.

OK, außer bei eingebundenen Resourcen ( .RES ), wo Delphi leider alles einbindet, welches in irgendeiner Datei ( .PAS / .DPR ) verlinkt ist.
(das verursacht übrigens einen gewissen Teil unserer "rießigen" Delphi-Anwenungen)

[Stevie]

Zitat von himitsu:

Also irgendwo den Klassennamen benutzen und alle Methoden aufrufen.

Stimmt nur halb. Methoden mit der Sichtbarkeit public/published werden auf jeden Fall kompililert. Für Methoden mit der Sichtbarkeit private bekommst du einen Hint und sie werden nicht einkompiliert (was auch Sinn macht, denn wer außer die Klasse selber sollte sie aufrufen?). Methoden mit der Sichtbarkeit protected könnten "unter den Tisch" fallen. Dürfte aber auch kein Problem sein, denn sie werden entweder in der Klasse selber oder einer abgeleiteten aufgerufen. Sie fallen also nur dann raus, wenn sie tatsächlich nirgendwo aufgerufen werden.

Also hast du nur das Problem, dass die Klasse selber als nirgendwo benutzt erkannt wird und nicht kompiliert wird. Das kannst du einfach mit einem initialization Block in der jeweiligen Unit lösen. Dort kannst du zum Beispiel ein RegisterClass(TMyObject) machen oder einfach eine Dummy Methode aufrufen, die nix macht.

[sx2008]

Ich denke dass du deiner Lösung (RTTI und Delphi Internas bis an die Grenzen ausreizen) auf den Holzweg bist.
Immer an das KISS-Prinzip denken!
Leider hast du nirgends erklärt wozu du Strings in Objekte umwandeln möchtest und wie die Klassen aufgebaut sind.
Es gibt aber die Design-Pattern Class-Factory und Builder.

Delphi-Quellcode:

TGameObjFactory = class(TObject)
public
  class function CreatePlayer:TPlayer;
  class function CreateBomb:TBomb;
  class function CreateBlackHole:TBlackHole;

  class function CreateByString(const s:string):TGameBaseClass;
end; 


class function TGameObjFactory.CreatePlayer:TPlayer;
begin
  Result := TPlayer.Create;
end;

class function TGameObjFactory.CreateByString(const s:string):TGameBaseClass;
begin
  if s='player' then
    result := CreatePlayer
  else if s='bomb' then
    result := CreateBomb
  else if s='timebomb' then
  begin
    Result := CreateBomb;  TBomb(Result).Delay := 360;
  end
  else ...
end;

Eine saubere Lösung ohne Tricks und doppelten Boden.

[himitsu]

Nja, in Delphi gibt es ja auch schon eine Vorlage (quasi ein Designpattern) und zwar die VCL.

String (Klassenname aus der DFM) > ein Objekt erzeugen (also das Formular laden)

[moelski]

Moin !

Zitat:

Leider hast du nirgends erklärt wozu du Strings in Objekte umwandeln möchtest

Wir haben in unserer Anwendung RS232 Geräte eingebunden. Die Geräteklassen sorgen dafür das die Rohdaten der Geräte geprüft / verworfen / umgerechnet / ... werden.

Wenn der User nun sein Gerät auswählt hatte ich folgende Idee:
Ich durchsuche per RTTI alle vorhandenen Klassen. Und die Klassen die entweder einer bestimmten Namenkonvention folgen oder ein spezielles Attribut haben gebe ich dem User zur Auswahl.
Er selektiert dann sein Gerät (und damit die Geräteklasse) und ich nutze eben die Auswahl um meine Klasseninstanz zu erstellen.

Das hätte den Vorteil das man weitere Geräte hinzufügen kann, ohne sich an anderer Stelle Gedanken über die Einbindung zu machen.
Neue Geräte würden automatisch erkannt und dem User angeboten.

Derzeit haben wir ein Konstrukt das eben so ausschaut:
if name = 'test1' then Geraet := TLVTest1.Create.....

Aber wie geschrieben muss man dort bei jedem Gerät dafür sorgen das es eben auch dort eingetragen wird.
Ist sicher kein riesen Aufwand, aber ich wollte eben mal einen neuen Weg testen

[himitsu]

Was passiert, wenn zufällig irgendeine Klasse, welche mit deiner Nutung rein garnichts zu tun hat, zufällig einen passenden Klassennamen oder dieses Attribut besitzt?

Besser wäre es, wenn diese Klasse also z.B. von einem bestimmten Vorfahren abgeleitet ist, damit du direkt über diesen Vorfahren zugreifen kannst (nötige Methoden per virtual+override hinzugefügt).
Somit könnte man auch noch "sicherer" prüfen, ob die Klasse auch über die gewünschten Funktionen verfügt.

Wenn man da nun eh eine Unit (mit der Basisklasse) einbinden muß, dann wäre es ein Leichtes, dort eine Registrierungsstelle anzubieten, wo neue Klassen registriert werden.

Und schon hat man keinerlei Probleme mehr.
- registrierte (benutzte) Klassen werden nicht wegoptimiert
- die überschriebenen Methoden und in der Basisklasse verwendeten Methoden, beiben ebenfalls erhalten
- man hat nun eine wunderschöne und extrem leicht zu durchsuchende Liste alle wichten Klassen
und muß nun auch keine der anderen zigtausend Klassen rausfiltern, welche die RTTI unnötiger Weise mit auflistet.