"Unsterbliche" Klassen

[Neutral General]

Hi,

Also das hier ist keine Frage die Lebensnotwendig ist, aber da mir grad langweilig ist würde ich gerne mal wissen ob man eine Klasse irgendwie "unsterblich" machen kann habs mal so versucht aber das geht nicht so richtig^^

Delphi-Quellcode:

TUnvKlasse = class(TObject)
   public
    S: String;
    destructor Destroy; override;
  end;

var Klasse: TUnvKlasse;

destructor TUnvKlasse.Destroy;
var Seele: TUnvKlasse;
begin
   Seele := Self;
   inherited Destroy;
   Self := Seele;
   Self.S := 'Hallo';
end;

dann hab ich halt zwei Buttons:

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
begin
 Klasse := TUnvKlasse.Create;
 Klasse.S := 'Test';
 Caption := TUnvKlasse.S; // Caption wird 'Test' ... logischerweise^^
end;

procedure TForm1.Button2Click(Sender: TObject);
begin
 Klasse.Destroy;
 Caption :=Klasse.S; // es gibt keine AV aber es steht auch nix da bzw es steht '' da
                            // wenn ich nochmal drücke gibts ne AV^^
end;

Geht das irgendwie ? :mrgreen:
Ich glaube das hier gehört schon fast in Klatsch und Tratsch^^..

Gruß
Michael

[DGL-luke]

durch das seele := self lenkst du nur die referenz um. wenn dann müsstest du den konstruktor einfach leer lassen...

[Neutral General]

Sogar ein leerer Destructor nützt nichts :D

[DGL-luke]

wieso? wird der speicher gleich dealloziiert? ohne das inherited destroy; wird doch nichts freigegeben... ausser das findet im free statt... kann man das überschreiben?

[Neutral General]

Ich rufe ja nur Destroy auf...
und mein Destructor ist leer..

[Dax]

Es geht: Überschreibe FreeInstance der Klasse und tue darin nichts, nicht mal inherited. Auch wenn ich den Sinn der Aktion nicht sehe... :gruebel:

[Neutral General]

Ok danke es klappt :D

Naja das hat kein Sinn aber da mir langweilig war wollte ich mal ne Unzerstörbare Klasse erschaffen xD :mrgreen:

[jbg]

Zitat:

Zitat von Neutral General

Naja das hat kein Sinn aber da mir langweilig war wollte ich mal ne Unzerstörbare Klasse erschaffen xD :mrgreen:

Na das hätte man auch einfacher haben können: Einfach nicht .Free aufrufen.

[Neutral General]

Ja das wäre genauso wie wenn man sagen würde: Ein Mensch ist auch unsterblich solange man ihn nicht umbringt...(oder er an altersschwäche stirbt^^)

Das Objekt muss ja immun gegen alle Angriffe sein :mrgreen: :freak:

[Airblader]

Per Holzhammermethode könntest du theoretisch so oder so die Klasse "kaputtieren" ;)

air

[Neutral General]

Wie denn das ?^^

Doch nicht etwa durch FreeAndNil ?? -.-
Dann werde ich erst FreeAndNil zerstören müssen :mrgreen:

[alzaimar]

Rechner ausschalten :wall:

[Die Muhkuh]

Zitat:

Zitat von alzaimar

Rechner ausschalten :wall:

:mrgreen:

[Neutral General]

...

Das ist unfair -.-^^

[Neotracer64]

Speicherresidenz und Autostart einbauen. :mrgreen:

[tommie-lie]

Zitat:

Zitat von Airblader

Per Holzhammermethode könntest du theoretisch so oder so die Klasse "kaputtieren" ;)

Zitat:

Zitat von Neutral General

Wie denn das ?^^

Im Zweifelsfall so wie FreeInstance es auch macht: Aufräumen und den Speicher wegwerfen. Je nachdem was du mit der Klasse angestellt hast bringt schon ein Typekarsten nach TObject den gewünschten Effekt.

Zitat:

Zitat von Neutral General

Doch nicht etwa durch FreeAndNil ?? -.-
Dann werde ich erst FreeAndNil zerstören müssen :mrgreen:

FreeAndNil ist keine Methode, sondern eine normale Prozedur, ohne die SysUtils.pas zu manipulieren kannst du sie nicht verändern.

Versuche mit Destruktoren sind übrigens von vornherein zum Scheitern verurteilt, weil die Compiler-Magic sich um das Freigeben des Objektes kümmert, unabhängig davon ob im Destruktor irgendwas anderes behauptet wird, oder nicht. Das Freigeben der Instanz ist also nicht Sache des Destruktors, sondern geschieht immer und automatisch. Der Destruktor ist mit einem Event vergleichbar, daß ausgeführt wird, bevor die Klasse endgültig über den Jordan wandert.

[Bernhard Geyer]

Wie wäre es Du die Klasse in einer eigenen Unit kapselst und die Schnittstelle per Interface bereitstellst und z.B. schon im Initialisierungsabschnitt einen Interfacepointer darauf holst. Um ganz sicher zu sein überschreibst du auch noch die _Release-Methode um zu verhindern das ein "Bösewicht" die automatische Referenzzählung von Delphi überwinden will.

[Neutral General]

Ich hab ne Idee: Ich erstelle eine "Unverwundbare" Klasse. Ich geb euch den Quellcode von nem Programm mit ner Unverwundbaren Klasse. Ihr dürft verändert was ihr wollt, aber ihr dürft keine Functionen,Proceduren oder Variabel oder so von der Klasse verändern oder hinzufügen. Wer es zuerst schafft die Klasse zu zerstören hat gewonnen :mrgreen:

(Das war ernst gemeint ;))

[NicoDE]

Zitat:

Zitat von Neutral General

Ihr dürft verändert was ihr wollt, aber ihr dürft keine Functionen,Proceduren oder Variabel oder so von der Klasse verändern oder hinzufügen.

Sind ClassHelper und eigene Compiler erlaubt? ;)

[Neutral General]

Eigene Compiler... eh mal sehn^^
Classhelper vielleicht wenn ich weiß was das ist :mrgreen:

(Bin am Rumbauen^^: Meine Klasse überlebt schon :

Delphi-Quellcode:

Klasse.Free;
Klasse.Destroy;
Klasse.FreeInstance;
FreeAndNil(Klasse);
TAndereKlasse(Klasse).Free

MUHAHAHAA ^^)

[NicoDE]

Zitat:

Zitat von Neutral General

(Bin am Rumbauen^^: Meine Klasse überlebt schon :

Delphi-Quellcode:

Klasse.Free;
Klasse.Destroy;
Klasse.FreeInstance;
FreeAndNil(Klasse);
TAndereKlasse(Klasse).Free

MUHAHAHAA ^^)

Jemand könnte auf die Idee kommen die Klassen-Definition in der Exe zur Laufzeit zu patchen...

[Neutral General]

Hehe ich glaube ich weiß sogar wie ich das abwenden kann :mrgreen:

[jim_raynor]

Im Prinzip gibts eine ganz einfache Methode. An Adresse null steht immer der Zeiger auf die VMT (virtual Method Table) in der die Verweise zu den überschrieben Methoden drin stehen. Man muss ganz einfach die Adresse der VMT auf die von TObject umlenken :lol: Dann funktioniert auch wieder der Aufruf von FreeInstance. hehe.

[Neutral General]

Bis jetzt müsst ihr noch keine Angst haben -.-^^
Mein Problem im Moment ist :

Delphi-Quellcode:

Meine(Un)VerwundbareKlasse := nil;

-.-^^

Und das abzuwenden ist irgendwie ein Problem grad :mrgreen:

[malo]

Zitat:

Zitat von Neutral General

Und das abzuwenden ist irgendwie ein Problem grad :mrgreen:

Das ist ja auch kein Zerstören. Damit löschst du ja nur den Zeiger auf das Objekt. Das Objekt liegt weiterhin im Arbeitsspeicher, nur das Programm weiß nicht mehr, wo das liegt. So in etwa :mrgreen:

Aber eventuell könntest du ja eine Standard-Property definieren, die du stattdessen auf Nil setzen würdest. Dann dürfte der Pointer noch auf das Objekt zeigen, aber ein anderer Pointer wird gelöscht... ;)

[tigerman33]

Funktionieren Standardproperties nicht nur für array-Eigenschaften?

[Neutral General]

Zitat:

Zitat von malo

Zitat:

Zitat von Neutral General

Und das abzuwenden ist irgendwie ein Problem grad :mrgreen:

Das ist ja auch kein Zerstören. Damit löschst du ja nur den Zeiger auf das Objekt. Das Objekt liegt weiterhin im Arbeitsspeicher, nur das Programm weiß nicht mehr, wo das liegt. So in etwa :mrgreen:

Aber eventuell könntest du ja eine Standard-Property definieren, die du stattdessen auf Nil setzen würdest. Dann dürfte der Pointer noch auf das Objekt zeigen, aber ein anderer Pointer wird gelöscht... ;)

Das hört sich irgendwie schon gut an.. Aber wie meinst du das mit der Property ?
Ich muss ja verhindern das

Delphi-Quellcode:

Klasse := nil;

seine Wirkung verliert, bzw das die Klasse schnell wieder ihren Zeiger wiederbekommt oder ihn erst gar nicht verliert..

[Dax]

Hey.. Eine Klasse besitzt ihren Zeiger nicht. Du besitzt den Zeiger auf die Klasse.. Also hilft nur, deinen Zeiger auf die Klasse mit einem Schreibschutz zu versehen.

[malo]

Ich weiß nicht, ob es wirklich funktioniert, aber ich dachte an sowas:

Delphi-Quellcode:

property Irgendwas: Pointer read fIrgendwas write fIrgendwas; default;

Eventuell funktioniert es ja. Ist jedoch nicht getestet.

[Neutral General]

Ah ja.. soweit zur Theorie... ^^
Und wie sieht die Praxis aus ? (Bitte wenigstens ein Ansatz, ich muss ja sagen das ich die Unverwundbare Klasse erfunden hab xD)

[Dax]

Die Praxis? Read-Only-Property einer Klasse. Anders gehts _nicht_. ;)

[Neutral General]

Das heißt ich muss es schaffen den Pointer meiner Klasse readonly zu machen ?
Na super.. Die Klassen haben ja nichtmal ne Eigenschaft Pointer...
Wie soll man sowas denn Readonly machen ?^^

NEIN ich glaube ich muss die komplette Klasse Readonly machen ^^

[Dax]

Erm, du verstehst das falsch.

Delphi-Quellcode:

type TForm1 = class(TForm)
  ..
  private
    fKlasse: TMeineUnsterblicheKlasse;
  public
   property UnsterblicheKlasse: TMeineUnsterblicheKlasse read fKlasse;
  end;

Oder so in der Art. Jedenfalls so, das der Zugriff auf den Pointer nie schreibend sein darf.

[MaBuSE]

Zitat:

Zitat von Neutral General

Delphi-Quellcode:

Klasse.Free;
Klasse.Destroy;
Klasse.FreeInstance;
FreeAndNil(Klasse);
TAndereKlasse(Klasse).Free

Delphi-Quellcode:

Teste mal TObject(Klasse).FreeInstance;

[NicoDE]

Zitat:

Zitat von Neutral General

Ich muss ja verhindern das

Delphi-Quellcode:

Klasse := nil;

seine Wirkung verliert, bzw das die Klasse schnell wieder ihren Zeiger wiederbekommt oder ihn erst gar nicht verliert..

Ähm, 'Klasse' scheint eine Referenz auf ein Objekt (Instanz einer Klasse) zu sein... das hat nichts mit deiner Klasse zu tun.

[tigerman33]

@Dax:
Das geht nicht. Er will ja, dass niemand eine Instanz seiner Klasse zerstören kann, also auch ohne "selbstauferlegte" Beschränkungen. Ist also quasi eine Art vollkommen sinnloser API. :mrgreen: (Das ist aber nicht negativ gemeint)

@malo:
Nein, das geht nicht. Default-Eigenschaften kann man nur für Array-Eigenschaften angeben--siehe oben.

[Neutral General]

Zitat:

Zitat von MaBuSE

Zitat:

Zitat von Neutral General

Delphi-Quellcode:

Klasse.Free;
Klasse.Destroy;
Klasse.FreeInstance;
FreeAndNil(Klasse);
TAndereKlasse(Klasse).Free

Delphi-Quellcode:

Teste mal TObject(Klasse).FreeInstance;

Eh was willst du mir damit sagen ?
Also meine Klasse ist immun gegen TObject(Klasse).FreeInstance...
Und das von Natur aus :mrgreen:

Aber immernoch nicht gegen Klasse := nil; -.-^^

@Tigerman(@Dax): Genau. Also die Klasse soll keine Property sein. Bzw sie muss keine sein aber trotzdem "unverwundbar" :mrgreen:

[MaBuSE]

Zitat:

Zitat von Neutral General

Eh was willst du mir damit sagen ?
Also meine Klasse ist immun gegen TObject(Klasse).FreeInstance...
Und das von Natur aus :mrgreen:

Kannst Du mal den Quellcode Deiner Klasse posten, ich würde das gerne mal sehen.

Dann kann ich selbst ausprobieren, ob TObject(Klasse).Free; funktioniert.

[ichbins]

Wie wärs wenn du den Inhalt deines Zeigers und einen Zeiger auf den Zeiger als protected-Variablen in deiner Klasse speicherst? Dann machst du eine Endlosschleife in die Klasse rein, in der du überprüfst, ob sich der Wert im Zeiger verändert hat.

Und: :=nil ist WIRKLICH kein Zerstören: Es bedeutet ja nur dass das Prog nicht mehr weiss wo im RAM die Klasse eigentlich ist. Dann könntest du die Klasse auch in einer lokalen Variable öffnen, die ist dann auch "verloren" wie bei :=nil.

[MaBuSE]

Zitat:

Zitat von Neutral General

Ich hab ne Idee: Ich erstelle eine "Unverwundbare" Klasse. Ich geb euch den Quellcode von nem Programm mit ner Unverwundbaren Klasse. Ihr dürft verändert was ihr wollt, aber ihr dürft keine Functionen,Proceduren oder Variabel oder so von der Klasse verändern oder hinzufügen. Wer es zuerst schafft die Klasse zu zerstören hat gewonnen :mrgreen:

(Das war ernst gemeint ;))

Also was ist?