Record, Object, Class. Warum nicht nur Object?

Für alles, was in den übrigen Lazarusthemen keinen Platz, aber mit Lazarus zutun hat.

Re: Record, Object, Class. Warum nicht nur Object?

Beitragvon mse » 6. Jun 2017, 05:11 Re: Record, Object, Class. Warum nicht nur Object?

kupferstecher hat geschrieben: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.
mse
 
Beiträge: 1986
Registriert: 16. Okt 2008, 09:22
OS, Lazarus, FPC: Linux,Windows,FreeBSD,(MSEide+MSEgui 4.6,git master FPC 3.0.4,fixes_3_0) | 
CPU-Target: x86,x64,ARM
Nach oben

Beitragvon mschnell » 6. Jun 2017, 09:30 Re: Record, Object, Class. Warum nicht nur Object?

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

Und was mit Properties ?
-Michael
mschnell
 
Beiträge: 3226
Registriert: 11. Sep 2006, 09:24
Wohnort: Krefeld
OS, Lazarus, FPC: svn (Window32, Linux x64, Linux ARM (QNAP) (cross+nativ) | 
CPU-Target: X32 / X64 / ARMv5
Nach oben

Beitragvon mse » 6. Jun 2017, 09:47 Re: Record, Object, Class. Warum nicht nur Object?

Properties sind entweder Daten oder Daten+Verhalten wenn sie entsprechende setter und/oder getter Methoden haben.
mse
 
Beiträge: 1986
Registriert: 16. Okt 2008, 09:22
OS, Lazarus, FPC: Linux,Windows,FreeBSD,(MSEide+MSEgui 4.6,git master FPC 3.0.4,fixes_3_0) | 
CPU-Target: x86,x64,ARM
Nach oben

Beitragvon mschnell » 6. Jun 2017, 10:40 Re: Record, Object, Class. Warum nicht nur Object?

Ich meinte bezüglich der Unterscheidung bzw nicht-Unterscheidung zwischen "record", "object", und "class".
-Michael
mschnell
 
Beiträge: 3226
Registriert: 11. Sep 2006, 09:24
Wohnort: Krefeld
OS, Lazarus, FPC: svn (Window32, Linux x64, Linux ARM (QNAP) (cross+nativ) | 
CPU-Target: X32 / X64 / ARMv5
Nach oben

Beitragvon mse » 6. Jun 2017, 10:44 Re: Record, Object, Class. Warum nicht nur Object?

Da Properties Verhalten haben können stehen sie für Records nicht zur Verfügung.
mse
 
Beiträge: 1986
Registriert: 16. Okt 2008, 09:22
OS, Lazarus, FPC: Linux,Windows,FreeBSD,(MSEide+MSEgui 4.6,git master FPC 3.0.4,fixes_3_0) | 
CPU-Target: x86,x64,ARM
Nach oben

Beitragvon mschnell » 6. Jun 2017, 14:35 Re: Record, Object, Class. Warum nicht nur Object?

Die Fakten kenne ich natürlich :D

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

-Michael
mschnell
 
Beiträge: 3226
Registriert: 11. Sep 2006, 09:24
Wohnort: Krefeld
OS, Lazarus, FPC: svn (Window32, Linux x64, Linux ARM (QNAP) (cross+nativ) | 
CPU-Target: X32 / X64 / ARMv5
Nach oben

Beitragvon mse » 6. Jun 2017, 14:48 Re: Record, Object, Class. Warum nicht nur Object?

mschnell hat geschrieben:Die Fakten kenne ich natürlich :D

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

-Michael

Eben. Verhalten hat in Records nichts zu suchen, dafür gibt es Objekte.
mse
 
Beiträge: 1986
Registriert: 16. Okt 2008, 09:22
OS, Lazarus, FPC: Linux,Windows,FreeBSD,(MSEide+MSEgui 4.6,git master FPC 3.0.4,fixes_3_0) | 
CPU-Target: x86,x64,ARM
Nach oben

Beitragvon pluto » 5. Sep 2018, 23:51 Re: Record, Object, Class. Warum nicht nur Object?

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.
MFG
Michael Springwald
Aktuelles Projekt: PlutoArduino
pluto
 
Beiträge: 6670
Registriert: 19. Nov 2006, 12:06
Wohnort: Oldenburg/Oldenburg
OS, Lazarus, FPC: Linux Mint 18.3 | 
CPU-Target: AMD
Nach oben

Beitragvon pluto » 5. Sep 2018, 23:54 Re: Record, Object, Class. Warum nicht nur Object?

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:
viewtopic.php?f=9&t=11268&p=100214&hilit=object#p100214
MFG
Michael Springwald
Aktuelles Projekt: PlutoArduino
pluto
 
Beiträge: 6670
Registriert: 19. Nov 2006, 12:06
Wohnort: Oldenburg/Oldenburg
OS, Lazarus, FPC: Linux Mint 18.3 | 
CPU-Target: AMD
Nach oben

Beitragvon mse » 6. Sep 2018, 06:34 Re: Record, Object, Class. Warum nicht nur Object?

pluto hat geschrieben: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.
mse
 
Beiträge: 1986
Registriert: 16. Okt 2008, 09:22
OS, Lazarus, FPC: Linux,Windows,FreeBSD,(MSEide+MSEgui 4.6,git master FPC 3.0.4,fixes_3_0) | 
CPU-Target: x86,x64,ARM
Nach oben

Beitragvon thosch » 6. Sep 2018, 09:57 Re: Record, Object, Class. Warum nicht nur Object?

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
 
   hr:=DD.EnumDisplayModes(0, nil, nil, @EnumAllModesCallBack);
 
   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!!!
thosch
 
Beiträge: 131
Registriert: 10. Jul 2017, 19:32

Beitragvon mse » 6. Sep 2018, 10:10 Re: Record, Object, Class. Warum nicht nur Object?

thosch hat geschrieben: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.
mse
 
Beiträge: 1986
Registriert: 16. Okt 2008, 09:22
OS, Lazarus, FPC: Linux,Windows,FreeBSD,(MSEide+MSEgui 4.6,git master FPC 3.0.4,fixes_3_0) | 
CPU-Target: x86,x64,ARM
Nach oben

Beitragvon pluto » 6. Sep 2018, 11:11 Re: Record, Object, Class. Warum nicht nur Object?

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?
MFG
Michael Springwald
Aktuelles Projekt: PlutoArduino
pluto
 
Beiträge: 6670
Registriert: 19. Nov 2006, 12:06
Wohnort: Oldenburg/Oldenburg
OS, Lazarus, FPC: Linux Mint 18.3 | 
CPU-Target: AMD
Nach oben

Beitragvon mse » 6. Sep 2018, 11:28 Re: Record, Object, Class. Warum nicht nur Object?

pluto hat geschrieben: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.
mse
 
Beiträge: 1986
Registriert: 16. Okt 2008, 09:22
OS, Lazarus, FPC: Linux,Windows,FreeBSD,(MSEide+MSEgui 4.6,git master FPC 3.0.4,fixes_3_0) | 
CPU-Target: x86,x64,ARM
Nach oben

Beitragvon Warf » 6. Sep 2018, 11:37 Re: Record, Object, Class. Warum nicht nur Object?

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.
Warf
 
Beiträge: 984
Registriert: 23. Sep 2014, 16:46
Wohnort: Aachen
OS, Lazarus, FPC: Mac OSX 10.11 | Win 10 | FPC 3.0.0 | L trunk | 
CPU-Target: x86_64, i368, ARM
Nach oben

» Weitere Beiträge siehe nächste Seite »
VorherigeNächste

Zurück zu Sonstiges



Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 4 Gäste

porpoises-institution
accuracy-worried