Kennt dein Compiler nullptr
?
-> das Problem ist, er hat keinen Computer-Compiler sondern einen 8Bit Microcontroler mit einstellig !KB!-
RAM und 2stellig !KB! (Flash)Rom...
So Feinheiten wie "nullptr" aus "C++V11" sind da nicht wirklich wichtig, zumal man in C/C++ bei Bedarf sehr einfach "auf alles" casten kann.
Adruino ist ne super Basis für den Embedded Einstieg. Das OO Konzept HW-Shield's per einfacher statischer Definition(C++ ClassStruct ala "Delphi Record") mit sofort verfügbarer und einfach nutzbarer Funktionalität "an alle" zu verteilen hat schon was.
Allerdings sollten wenigsten die, welche die "Shield's" programmieren mit den Grundregeln der HW nahen nunmal Address & Pointer basierten C/C++ Programmierung vertraut sein.
Leider ist dies nicht immer der Fall. Ich kaufe auch gerne billigste Test-HW als "Adruino-Shield" und mache mittlerweile als erstes aus dem Adruino C++-Code wieder einen simple C-Code, welcher die Funktion ganz ohne OO im C-File hat und alles was Hardware spezifisch ist wird im H-File via Defines "auf externes gemappt" oder wenn möglich hier direkt zugeordnet.
Flexible HW Nutzung ist eine nicht unübliche Herausforderung, nur frage ich mich, ob es hier unbedingt der Objektorientierung Bedarf!?... Da gibt es seit Jahrzehnten bewährt das #IFDEF HAS_XY... so wird auch wirklich nur das übersetzt und gelinkt was real vorhanden&benötigt. Das spart dann nicht nur den
RAM, sondern auch den Programmspeicher als ROM!!! Ich denke der TE sollte sich bei wirklichem Interesse an guter Speicheroptimierung mehr in dieser Richtung orientieren. In C/C++ geht quasi stets "alles", egal ob jeweils sinnvoll oder nicht
