TObject = Object ?

[Neutral General]

Hi,

Ich habe grad das Object (neu)entdeckt. Wenn man Klassen so definiert:

Delphi-Quellcode:

TKlasse = Object

dann ist hat die Klasse wie records keine Eigenschaften. ABER sie kann proceduren beinhalten...
Und man hat nicht das lästige Zeug von TObject (ob lästig oder notwendig sei mal dahingestellt :mrgreen:) :)
Eigentlich die perfekte Klasse :D

So jetzt zur Hauptfrage:

Jedenfalls hatte ich dann die Theorie das TObject von Object abgleitet sein könnte. Was ich logisch finde.
Aber in der Definition steht

Delphi-Quellcode:

TObject = class

Aber wie kann das sein ?

Delphi-Quellcode:

TIrgendeineKlasse = class

 <=>

TIrgendeineKlasse = class(TObject)

:arrow:

Delphi-Quellcode:

TObject = class(TObject)

Aber das ist ein noch größerer Unsinn..

Gruß Michi

[Ultimator]

War die Verwendung von object nicht früher beim objektorientieren TP State-of-the-Art und später dann in Delphi kam class?

Und

Delphi-Quellcode:

MyObject = class
//und
MyObjectZwo = class(TObject)

sind das Gleiche.

[Neutral General]

Zitat:

Zitat von Ultimator

Und

Delphi-Quellcode:

MyObject = class
//und
MyObjectZwo = class(TObject)

sind das Gleiche.

Ja genau deswegen ja.

Und da

Delphi-Quellcode:

TObject = class

gilt, gilt genauso auch

Delphi-Quellcode:

TObject = class(TObject)

was aber Unsinn ist.

[Der_Unwissende]

Hi,
Ja, kann Ultimator natürlich nur zustimmen, möchte hier aber dann auch gleich auf die Forum-Suche verweisen! Da findest du schon genügend zu Object vs. TObject.

Das eine Klasse ohne Angabe von einer speziellen Klasse immer von TObject abgeleitet wird ist natürlich einfach nur dem Compiler zu verdanken, der einfach nachschauen kann ob es eine Basisklasse gibt (sonst TObject).
Natürlich kann der auch mit der Definition von TObject umgehen ohne sich hier rekursiv einen Kreis zu bauen.

Gruß Der Unwissende

[Khabarakh]

TObject befindet sich nicht umsonst in der Unit, in der die Hochsprache aufhört und die Compiler-Magic anfängt :zwinker: .

[arbu man]

Tatsächlich ist TObject auch von class abgeleitet. Das ganze steht in der unit system die bei jeden Delphi Projekt dabei ist, somit ist TObject nicht von Object abgeleitet.

Delphi-Quellcode:

  TObject = class
    constructor Create;
    procedure Free;

    ...

    destructor Destroy; virtual;
  end;

[Neutral General]

ABER: Nach euren Theorien müsste ja bei folgendem Beispiel THallo von class abgeleitet sein und nicht von TObject...

Delphi-Quellcode:

unit Unit1;

interface

// KEINE Uses.. kein TObject und nix

type
THallo = class
 Hallo: String;
 procedure SetHallo;
end;

implementation

{ THallo }

procedure THallo.SetHallo;
begin
 Hallo := 'Hallo';
 Self.Destroy; // Und alle anderen TObject Methoden sind verfügbar
end;

end.

[JasonDX]

Moment, hier scheinen manche etwas zu verwechseln:
TObject ist eine Klasse, die in Delphi deklariert wurde.
Object ist ein Schlüsselwort, das noch aus Pascal-Zeiten stammt und sowas wie ein vorreiter des class-Keywords war.
Object hat also nix mit TObject zu tun, und man kann auch nicht eine Klasse von object ableiten.
Lasst euch nicht durch die ähnliche Namensgebung drausbringen ;)
Und bezüglich TObject/class/CompilerMagic: Man kann nicht 'von class ableiten'. TObject ist eine Klasse, welche stinknormal implementiert wurde. CompilerMagic tritt ein, wenn eine Klasse (außer TObject) deklariert wird, die keine andere Klasse erbt: Dann wird nämlich automatisch TObject vererbt.


greetz
Mike

[Neutral General]

Aber ich meine es wäre logisch wenn TObject = Object wäre und das Object hätte dann halt die ganzen Methoden verpasst bekommen und dann wurden die anderen folgenden Komponenten halt von TObject abgleitet. Was ist denn TObject sonst ?

[Khabarakh]

Zitat:

Zitat von Neutral General

Delphi-Quellcode:

// KEINE Uses.. kein TObject und nix

System.pas wird automatisch in jede Unit eingebunden :wink: .

Zitat:

Zitat von Neutral General

Aber ich meine es wäre logisch wenn TObject = Object wäre und das Object hätte dann halt die ganzen Methoden verpasst bekommen und dann wurden die anderen folgenden Komponenten halt von TObject abgleitet.

Object und TObject haben nichts miteinander zu tun, Punkt :P :mrgreen: .

Zitat:

Was ist denn TObject sonst ?

Eine Klasse ohne Basisklasse. Da das mit der Delphi-Language schlecht möglich ist, besteht TObject eben zur Hälfte aus Assembler.

[Neutral General]

Das wird mir langsam zu hoch :mrgreen:
TObject ist für mich ein Mysterium^^

Naja vielleicht nicht mehr soviel wie vor ein paar Minuten aber trotzdem ;)
Danke für die Antworten und den Versuch mir was zu erklären :D

Gruß
Michael

[jbg]

Zitat:

Zitat von Neutral General

Aber ich meine es wäre logisch wenn TObject = Object wäre und das Object hätte dann halt die ganzen Methoden verpasst bekommen und dann wurden die anderen folgenden Komponenten halt von TObject abgleitet. Was ist denn TObject sonst ?

class und object sind zwei verschienene Konzepte. Das ältere object ist nichts anderes als ein record, der Methoden, eine VMT und eine DMT hat. object Objekte werden immer auf dem Stack oder im Datensegment angelegt, wenn man keine Zeiger-Typ darauf nutzt.

Delphi-Quellcode:

PMyObject = ^TMyObject;
TMyObject = object
  constructor Init(const A: string);
  destructor Done;
  procedure Haha; virtual;
end;

var
  P: PMyObject;
begin
  P := New(PMyObject, Init('Hallo'));
  P^.Haha;
  Dispose(P, Done);
end;

Ein class Objekt liegt immer im Heap (freier Speicher) und nutzt um einiges mehr Compilermagic als das alte object. Das fängt schon beim Konstruktor an, der nicht aus einer Methode besteht sondern aus meheren (NewInstance + Create + AfterConstruction). Der Compiler versteckt das aber vor unseren Augen.

TObject is eine class und kein object. Die beiden Arten von "Klassen" sind nicht binärkompatibel. So liegt bei class die VMT immer an Offset 0, wohingegen bei object die VMT erst dann eingefügt wird, wenn die erste virtuelle Methode zum Objekt hinzukommt. Alle vorher definierten Felder verschieben also den Offset des VMT-Zeigers bei object. Die VMT ist bei class eine Metaklasse (beschreibt also die Klasse selbst). Dies ermöglicht die Nutzung von virtuellen Konstruktoren und virtuellen Klassenmethoden (Stichwort: TClass = class of TObject). Bei object wird die VMT ihrem Namen mehr gerecht, denn dort ist sie nur eine Tabelle der virtuellen Methoden (Virtual Method Table) mit einem zusätzlichen DMT-Zeiger (Dynamic Method Table).

[jbg]

Zitat:

Zitat von Neutral General

TObject ist für mich ein Mysterium

Der Compiler kompiliert die System.pas in einem speziellen Modus, in dem er einiges anders verarbeitet als wenn man eingene Units kompiliert. Die System.pas und der Compiler hängen so stark zusammen, dass bei Änderungen am Compiler immer auch Änderungen an der System.pas notwendig sind.

[TheAn00bis]

Zitat:

Zitat von jbg

TObject is eine class und kein object. Die beiden Arten von "Klassen" sind nicht binärkompatibel. So liegt bei class die VMT immer an Offset 0, wohingegen bei object die VMT erst dann eingefügt wird, wenn die erste virtuelle Methode zum Objekt hinzukommt. Alle vorher definierten Felder verschieben also den Offset des VMT-Zeigers bei object. Die VMT ist bei class eine Metaklasse (beschreibt also die Klasse selbst). Dies ermöglicht die Nutzung von virtuellen Konstruktoren und virtuellen Klassenmethoden (Stichwort: TClass = class of TObject). Bei object wird die VMT ihrem Namen mehr gerecht, denn dort ist sie nur eine Tabelle der virtuellen Methoden (Virtual Method Table) mit einem zusätzlichen DMT-Zeiger (Dynamic Method Table).

Heißt das, dass ich ein Objekt (deklariert durch Txyz = Object) nicht erst über das .Create oder einen anderen Konstruktor erzeugen muss, sondern einfach eine Prozedur des Objekts ausführen kann? Oder hab ich das falsch verstanden?

[Neutral General]

Richtig.
Objecte können proceduren und functionen haben und Variablen. Haben aber von Natur aus keine Variablen oder Methoden genau wie Records. Und man muss sie genauso wie records nicht erstellen, kann aber trotzdem mit proceduren und Functionen arbeiten. Wie es jedoch mit OOP und Vererbung etc aussieht weiß ich nicht.

Beispiel:

Delphi-Quellcode:

 TMensch = Object
  Name: String
  Alter: Word;
  procedure Bewegen(x,y: Integer);
  function Ka: Boolean;
 end;

procedure TForm1.Button1Click(Sender: TObject);
var Ich: TMensch;
begin
  Ich.Name := 'Michael';
  Ich.Alter := 17;
  Ich.Bewegen(MeinZimmer.x,MeinZimmer.y);
end;

[TheAn00bis]

Hey Danke, spricht abgesehen von
Vererbung etwas gegen die Nutzung
von dieser Art von Objekten?
Aus jbgs Beitrag versteh ich nicht viel. :wink:

[jbg]

Eine VMT würde keinen Sinn machen, wenn man nicht erben kann:

Delphi-Quellcode:

type
  PFigure = ^TFigure;
  TFigure = object
    X, Y: Integer;

    constructor Init(AX, AX: Integer);
    destructor Done; virtual;
    procedure Draw; virtual;
  end;

  PCircle = ^TCircle;
  TCircle = object(TFigure)
    R: Integer;
    constructor Init(AX, AY, AR: Integer);
    destructor Done; override;

    procedure Draw; override;
  end;

  PRectangle = ^TRectangle;
  TRectangle = object(TFigure)
    X1, Y1: Integer;
    constructor Init(AX0, AY0, AX1, AY1: Integer);
    procedure Draw; override;
  end;

var
  DynFigure: PFigure;
  StaticFigure: TFigure; // behandeln wie einen Record
begin
  DynFigure := New(PRectangle, Init(10, 10, 20, 20));
  DynFigure^.Draw; // zeichnet ein Rechteck
  Dispose(DynFigure, Done);

  StaticFigure.Init(10, 10);
  StaticFigure.Draw; // zeichnet einen Punkt
  StaticFigure.Done;
end.

[Neutral General]

Übrigens wie ich gerade herausgefunden hab:
Vererbung FUNKTIONIERT !

[Die Muhkuh]

Aber nicht mit dem Quelltext von jbg.

[Neutral General]

Delphi-Quellcode:

Gebaeude = Object
   Flaeche: Integer;
   procedure Bauen;
  end;

  Haus = Object(Gebaeude)
   NeNeueVar: String;
   procedure Bauen;
  end;

1. Flaeche existiert auch in der Klasse Haus.
2. Man kann entweder "Bauen" so "überschreiben":

Delphi-Quellcode:

procedure Haus.Bauen;
begin
  Form1.Caption := 'Haus bauen!';
end;

oder/und die Methode einfach vererben:

Delphi-Quellcode:

procedure Haus.Bauen;
begin
  inherited;
  // eventuell weiterer Quelltext
end;