af0815 hat geschrieben: ↑Mo 31. Aug 2020, 19:54
Hast du dir den Thread angesehen, also ich würde es bei Arduino uno schon mal probieren. Wenn wer lust hat und es mit der Methode nicht funktioniert, dann muss man sowieso auf das alt hergebrachte zurück.
Ja, doch das kann auch in die hose gehen:
Du baust dein programm, alles super. Dann ein jahr später willst du das program verändern, lädst dir die komponente runter, deren neue version jetzt andere compiler switches benutzt oder manche der funktionen annotiert hat, und zack du hast einen haufen Linker fehler. Oder ein GCC update kommt raus der das optimization verhalten ändert, und jetzt hast du auf zwei rechnern ne unterschiedliche gcc version und es baut auf dem einen aber nicht auf dem anderen.
Das sind genau die arten von Fehlern die einem graue haare verpassen, weil man sich dann dumm und dämlich suchen muss in quelltext den man selbst nicht geschrieben hat (besonders wenn das nur bei bestimmten optimierungsstufen oder so vorkommt). Während wenn man einmal die klassen flatened, dann kan in der Lib und im Compiler intern passieren was will (solang sich natürlich nicht das C++ interface ändert), es funktioniert
Timm Thaler hat geschrieben: ↑Mo 31. Aug 2020, 22:13
Aber ob das gut geht? Bisher hab ich keine guten Erfahrungen mit object und AVR gemacht. Es wird jede Menge Overhead produziert.
Theoretisch gibt es nix was daran overhead erzeugen sollte (solang man natürlich kein RTTI oder so kram benutzt, falls das mit objects überhaupt geht).
Ich hatte allerdings mal ein paper gelesen was die procedural (C) und OOP (C++) auf eingebetteten systemen vergleicht, und hat eine starke OOP penalty festgestellt (10%-20% performance, 20%-40% größe, 10%-15% stromverbrauch):
Link
Das vergleicht aber im allgemeinen OOP patterns mit proceduralen patterns, ist also kein Code der für Embedded systems optimiert wurde, sondern code der so geschrieben wurde um möglichst viel High-Level OOP kram zu benutzen (z.b. iteratoren), da kann man bestimmt also noch was rausholen.
Und zumindest in sehr kleinen test programmen produzieren variablen und funktionen und advanced records mit methoden das selbe assembly beim fpc (zumindest auf x86). Klar, wenn man jetzt objects mit vtables benutzt, kann das das program ganz schön aufblähen