Record, Object, Class. Warum nicht nur Object?

[mse]

Ich vermute, dass du Pointer eben schon so verinnerlicht hast, dass du das Problem der verschobenen Logik gar nicht mehr siehst, nämlich die, dass man auf den Wert eines Integer direkt zugreift, zum Zugriff auf den Wert eines Integer-Pointers jedoch manuell dereferenzieren muss.

Für mich sind Pointer mit den damit möglichen Operationen Daten wie alle anderen auch. Integer und Real können z.B. multipliziert werden, mit String geht multiplizieren nicht. Die erlaubten Operationen für Pointer sind unter Anderem Dereferenzierung ("^") und Adressverschiebung ("+"), das ist der ganze Zauber.

[mschnell]

Zum Unterschied zwischen "record" und "object": ein Record beinhaltet ausschliesslich Daten, ein Objekt kann zusätzlich Verhalten (= Methoden) haben.

Und was mit Properties ?
-Michael

[mse]

Properties sind entweder Daten oder Daten+Verhalten wenn sie entsprechende setter und/oder getter Methoden haben.

[mschnell]

Ich meinte bezüglich der Unterscheidung bzw nicht-Unterscheidung zwischen "record", "object", und "class".
-Michael

[mse]

Da Properties Verhalten haben können stehen sie für Records nicht zur Verfügung.

[mschnell]

Die Fakten kenne ich natürlich

Wir diskutieren doch gerade, wie man es idealer Weise machen sollte

-Michael

[mse]

Die Fakten kenne ich natürlich

Wir diskutieren doch gerade, wie man es idealer Weise machen sollte

-Michael

Eben. Verhalten hat in Records nichts zu suchen, dafür gibt es Objekte.

[pluto]

Ich grabe mal diesen vergrabenen Thread wieder aus *schaufel beiseite leg*....

Ich finde das eine sehr Interessante frage. Ich habe mir alle drei Seiten durchgelesen, kann aber bisher nicht verstehen, wo der Unterschied z.b. zwischen Class und Object ist.
Erst am Dienstag habe ich mich mit jemanden über dieses Thema unterhalten, er meint:
Es gibt Praktisch kein Unterschied zwischen CLASS und Object beide würden sich gleich verhalten.
Die Frage die dabei aufkam war: Warum hat man Object nicht weiter geführt und Stattdessen Class eingebaut?

Hier in den bisher drei Seiten Langen Thread konnte ich nur herrauslesen, dass es wohl Probleme mit dem Init von Eigenschafen/Variablen gibt, was sind genau die Unterschied?
In CLASS kann ich folgende Sachen machen:
1. Ich kann von anderen Classen Ableiten(Ein sehr praktische Funktion, wurde aber in Modernen Sprachen wie Rust gestrichen.... da durch sehr viele Probleme Entstehen können).

2. Ich kann Methoden hinzufügen, kann ich aber auch bei Record's

3. Ich habe ein constructor, destructor gibt es die auch bei Object?

4. Auf dem AVR werden CLASS nicht unterstützt, aber Object's... warum? Sind CLASS Intern Inkompatibel zu OBJECT?

5. Wenn ich nun ein "Interface" schreibe, für den AVR und für den PC, müsste ich ja über eine Kompiliere Direktive entscheiden, hier nutzte ich OBJECT und da nutzte ich CLASS, mehr Unterschiede gibt es eigentlich nicht oder?

6. Property's sind eine Praktische Sache, die kann ich bei CLASS einfügen, ich meine auch bei RECORD's bei OBJECT bin ich mir gerade nicht sicher.

[pluto]

Nachtrag:

Dynamische Klassen (class) dürften nicht funktionieren, das setzt ja eine dynamische Speicherverwaltung voraus. Bei Create wird der Speicher angefordert, ich kann mir aber irgendwie nicht vorstellen, dass ein Speichermanager implementiert ist.

Statische Objekte (object) funktionieren aber. Ich verwende das auch sehr gern, macht den Code oft lesbarer. Auf dem Desktop ist object eher ungewöhnlich, obwohl die Nutzung eigentlich komfortabler ist als bei Klassen, solange man eben die Instanzen zum Zeitpunkt des Programmierens schon zuweisen kann. Create gibts entsprechend nicht, der Speicher wird bei der Variablendeklaration reserviert (im Beispiel nach "var").

Stamm aus diesem Thread hier:
http://www.lazarusforum.de/viewtopic.ph ... ct#p100214

[mse]

Die Frage die dabei aufkam war: Warum hat man Object nicht weiter geführt und Stattdessen Class eingebaut?

Das waren vermutlich hauptsächlich Marketinggründe.
Wie MSElang zeigt, kann mit einem verbesserten "object" auch "class" abgebildet werden. "tobject" kann dann mit den "object"/"class" Grundelementen nachgebaut werden und kann - muss aber nicht - als Basis der Klassenhierarchie dienen.

[thosch]

Lasst doch einfach mal die Operatoren so, wie wir sie seit Turbo Pascal 7.0 kennen, ich habe gerade dieses Konstukt (fett gedruckt):

Code: Alles auswählen

 
function GetDDrawModes:hresult;
var
 DD : iDirectDraw;
 hr : hResult;
begin
  gfxNumModes := 0;
 
  DD:=nil;
 
 hr:=DirectDrawCreate(nil, DD, nil);
 
  if hr = DD_OK then begin
 
   [b]hr:=DD.EnumDisplayModes(0, nil, nil, @EnumAllModesCallBack);[/b]
 
   DD:=nil;
 
  end;
 
  GetDDrawModes:=hr;
end;
 

wo mir der Compiler diese Fehlermeldung ausspuckt:

WINDX.INC(48,62) Error: Incompatible type for arg no. 4: Got "<address of function(PDDSURFACEDESC;Pointer):LongInt;StdCall>", expected "<procedure variable type of function(PDDSURFACEDESC;Pointer):LongInt;CDecl>"

Warum, zum Teufel erkennt der Compiler dieses Kontrukt nicht an? In Delphi kann ich ohne Probleme auf diese Weise einen Prozedurzeiger (Adresse der Prozedur (oder Funktion) übergeben. Warm nicht auch in Freepascal?

Was soll ich da jetzt hier machen, damit ich die Adresse der Prozedur (oder Funktion) mit dem Namen EnumAllModesCallBack übergeben kann? Weglassen des "@"-Zeichens funktioniert hier nicht!

Nervig, wenn durch immer neue Konstrukte, die dann angeblich soooo viel besser sind als die alten, gewohnten, eingeführt werden, die der Programmierer aber dann nicht nutzen kann, weil sich die Syntax alle jubel-Jahre ändert!

Auch die Anwender der IDE programmieren zum großen Teil in ihrer kostbaren Freizeit. Auch jetz bei dem schönen Sommerwetter.

Lasst doch einfach die vorhandenen Sprachelemente, die vorhanden Syntax, wie sie schon immer war. Neue Sprachkonstrikte könnt Ihr dann gerne hinzufügen, aber bitte, ohne die alten einfach zu entfernen, weil die angeblich sooo uneffektiv sind. Ich komme da schneller, wenn ich die alten Konstrikte, wie ich sie seit Beginn von Turbo Pascal und Freepascal kenne einfach weiter verwenden kann und so das anvisierte Programm erst mal läuft. Optimieren, dann auch gerne unter evtl. extrm mühsamer Aneignung all der tollen neuen Konstrukte, kann ich später, wenn das Programm erst mal Läuft später immer noch!!!

[mse]

Ich komme da schneller, wenn ich die alten Konstrikte, wie ich sie seit Beginn von Turbo Pascal und Freepascal kenne einfach weiter verwenden kann und so das anvisierte Programm erst mal läuft. Optimieren, dann auch gerne unter evtl. extrm mühsamer Aneignung all der tollen neuen Konstrukte, kann ich später, wenn das Programm erst mal Läuft später immer noch!!!

Dann solltest du Free Pascal in den Turbo Pascal Mode versetzen. Der Delphi Modus ist vielleicht für dich vielleicht ebenfalls geeignet?
Dass im objfpc modus '@' als Addressoperator für Prozeduren und Funktionen verwendet wird ist AFAIK schon immer so gewesen.

[pluto]

Lasst doch einfach die vorhandenen Sprachelemente, die vorhanden Syntax, wie sie schon immer war. Neue Sprachkonstrikte könnt Ihr dann gerne hinzufügen, aber bitte, ohne die alten einfach zu entfernen, weil die angeblich sooo uneffektiv sind.

Dann ist Rust für dich eindeutig nicht das richtige: Da wird nämlich ohne Rücksicht auf Verluste, Sachen die Probleme machen einfach Entfernt und durch komplett neue Sachen ersetzt.

Wenn ich das jetzt richtig verstanden habe, ist der "einzigste" unterschied der, zwischen Statischem Speicher und Dynamischen Speicher?

[mse]

Wenn ich das jetzt richtig verstanden habe, ist der "einzigste" unterschied der, zwischen Statischem Speicher und Dynamischen Speicher?

"object" kann im Heap (= "dynamischer Speicher") oder als globale Variable oder als lokale Variable im Stack angelegt werden. "class" ist immer im Heap und wird via Pointer angesprochen. Das "class" Grundobjekt "tobject" hat schon einige Eigenschaften, Felder und Methoden, ein "object" Grundobjekt ist eigenschafts- und methodenlos. Free Pascal "object" kann AFAIK keine "interface" implementieren, auch sonst wurde "object" nicht weiterentwickelt. Ich weiss nicht welche weitere "class" Neuerungen in "object" fehlen.

[Warf]

Objects können verwendet werden ohne das der konstruktor und destruktor aufgerufen werden muss. Das ist ein absolutes nogo für mich da wenn ich ein Objekt Schreibe gehe ich immer Davon aus das am Anfang der konstruktor aufgerufen wird und am Ende der destruktor. C++ Objekte machen das automatisch, bei Pascal kann man das vergessen und so eine Fehler zu finden ist echt wiederlich. Bei Klassen kann man ohne konstruktor die Klasse gar nicht erst erzeugen und ohne destruktor bemerkt man es spätestens wenn man heaptrc verwendet.

Solang object diese dumme Fehlerquelle haben (die super einfach gefixt werden könnte wie in C++) verwende ich keine objects.