Record, Object, Class. Warum nicht nur Object?

[pluto]

Objects können verwendet werden ohne das der konstruktor und destruktor aufgerufen werden muss. Das ist ein absolutes nogo für mich da wenn

Das ist natürlich ein gutes Argument. Problem ist halt nur: AVR unterstützt, leider kein CLASS. Also: Entweder ohne OBJECT Arbeiten(Was auch nicht wirklich eine Lösung ist) oder mit RECORDS Arbeiten, was auch nicht unbedingt schön ist.

[Warf]

Das ist natürlich ein gutes Argument. Problem ist halt nur: AVR unterstützt, leider kein CLASS. Also: Entweder ohne OBJECT Arbeiten(Was auch nicht wirklich eine Lösung ist) oder mit RECORDS Arbeiten, was auch nicht unbedingt schön ist.

Kann man keinen eigenen Memory Manager implementieren der dann den heap in einem bestimmten Speicher Bereich verwaltet? Würde sich eventuell mal lohnen einen AVR heap zu implementieren den man dann veröffentlichen könnte um auch Klassen mit avr verwenden zu können. Man muss ja praktisch nur beim Start eine gewünschte Start und endaddresse angeben für den heap diese Adressen dann vom Memory Manager verwaltet lassen

Problematisch wird’s nur mit Special Memory bei manchen Controllern, da muss jeder halt selbst schauen welche Speicherbereiche zur Verfügung stehen

[pluto]

Kann man keinen eigenen Memory Manager implementieren der dann den heap in einem bestimmten Speicher Bereich verwaltet?

Das wäre natürlich, eine Lösung, aber wäre das Sinnvoll? Selbst wenn es ginge? ich glaube, es wäre Sinnvoller einfach auf AVR mit OBJECT zu Arbeiten und beim PC mit CLASS.
Das wird zwar Aufwendiger werden den Code zu schreiben, aber ich glaube das wäre ein guter Kompromiss.

[mse]

Das wird zwar Aufwendiger werden den Code zu schreiben, aber ich glaube das wäre ein guter Kompromiss.

Warum nicht auch auf dem PC mit "object" wenn die Routine auch auf einem uP laufen soll? Auch wenn dich gestandene Delphi Programmierer dafür belächeln oder anfeinden werden, wir wissen es ja besser.

[Warf]

Kann man keinen eigenen Memory Manager implementieren der dann den heap in einem bestimmten Speicher Bereich verwaltet?

Das wäre natürlich, eine Lösung, aber wäre das Sinnvoll? Selbst wenn es ginge? ich glaube, es wäre Sinnvoller einfach auf AVR mit OBJECT zu Arbeiten und beim PC mit CLASS.
Das wird zwar Aufwendiger werden den Code zu schreiben, aber ich glaube das wäre ein guter Kompromiss.

Ich würde es schocals sinnvoll erachten, das wäre einmalig ne Menge Aufwand und dafür hätte man dann den vollen Umfang von Pascal. Für die Uni hab ich mal einen Memory Manager fürn atmega 2560 in C geschrieben, der war zwar nicht so sonderlich schnell (hab keine Ahnung von AVR Optimierungen) und auch nicht sonderlich Platz effizient, war aber nur eine Woche Aufwand, ist also grundsätzlich nicht so kompliziert.
Man könnte glaube ich auch den Fpc MM verwenden wenn man die MMap calls durch statische Bereiche ersetzt.

[mse]

uP Programme müssen aber besonders schnell und platzsparend sein, darum fallen viele vom PC gewohnte Arbeitsweisen aus dem Rennen.

[pluto]

uP Programme müssen aber besonders schnell und platzsparend sein, darum fallen viele vom PC gewohnte Arbeitsweisen aus dem Rennen.

Wenn man sich die Arduino Umgebung genauer ansieht, könnte man den Eindruck gewinnen, dass dort "platzsparend" und "schnell" keine Argumente sind.
Z.B. wurde der String Typ eingeführt, der macht aber erst mit dem ESP oder STM sinn. Der speicher vom Tiny85 wäre wohl sofort Voll, je nach Anwendung.

Vielleicht gibt es ja eine Art Kompromiss zwischen besonders "platzsparend" und besonders "schnell"?

[mse]

Vielleicht gibt es ja eine Art Kompromiss zwischen besonders "platzsparend" und besonders "schnell"?

Häufig sind besonders platzsparende Programme auch besonders schnell. Es gibt einfach mehr zu studieren.

[Warf]

uP Programme müssen aber besonders schnell und platzsparend sein, darum fallen viele vom PC gewohnte Arbeitsweisen aus dem Rennen.

Was man auch machen könnte wäre einen MM für einen separaten SRAM zu machen (hatte ich damals auch für die Uni gemacht) für das bisschen SRAM was die uCs mitbringen wäre ein MM wahrscheinlich nicht die beste Option (außer eventuell für die richtig großen)
Aber ja das müsste auf jedenfall eine schlaue Datenstruktur verwenden (da wir damals auch ein multithreading Modell Eingebaut haben müsste man nicht nur Memory Locations sondern auch deren prozesszugehörigkeit speichern was den platzverbsuch vervierfacht hat (4 Bit = 15 mögliche Prozesse + 0 Index für freien Speicher ) für einen simplen MM reicht 1 Bit
Außerdem sollte das natürlich möglichst optimiert werden, ich kenn mich mit avr aber ned so gut aus daher war mein MM nicht so schnell damals

[thosch]

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.

Danke! Mit {$MODE DELPHI} funktioniert es mit der Übergabe der Prozeduradresse so wie es soll und wie ich es erwarte.

Welche Funktion hat dann aber der Adressoperator im objfpc Mode. Da meckert der Compiler an besagter Stelle.

[thosch]

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.

Korrekt, dann ist die Sprache RUST für mich nicht geeignet!

Danke schon mal für die Warnung!

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

Nein da kommt mindestens noch die unterschiedliche Syntax zwischen Recordvariablen und Zeigervariablen hinzu:

Record-Feld -> recvar.Feld

Zeiger auf Recordfeld -> recptr^.Feld

Außer bei Klassen, deren Instanzen wohl automatisch Zeiger sind und daher mit dem simplen Punkt referenziert werden, während in C/C++ auch da die Zeigersyntax verwendet wird:

unionptr->Feld
classvar->Member

Eigentlich in Pascal inkonsequent, aber mittelerweile habe ich mich an diese Schreibweise gewöhnt.

.

[mse]

Welche Funktion hat dann aber der Adressoperator im objfpc Mode. Da meckert der Compiler an besagter Stelle.

https://www.freepascal.org/docs-html/cu ... 4-620003.6
Wie sind denn "EnumDisplayModes" und "EnumAllModesCallBack" definiert?