Hm… das ist nervig, der Absturz ist bei if constexpr([...])
, das kennt c++11 natürlich nicht. Ich hatte hier mal beschrieben, was genau das macht (forciert den Compiler zur Optimierung der Verzweigung zur Compile-Zeit). Ist aber ein std++17 Feature und der gcc von Arduino 1.0 spricht leider nur c++11…
Aber wenn ich das repariere, tun sich einige andere Problemstellen auf (zB ESP_ARDUINO_VERSION_VAL
ist undefined, std::clamp
gibt es nicht, etc.).
Ich denke das sollten wir generell in der Dev-Branch ansprechen, ob Rückwärtskompatibilität zu Arduino 1.0 gewünscht ist.
Vorteil ist dass der Code pflegeleichter wird, wenn wir die Farben in globale Variablen raus ziehen. Und wenn jemand ein anderes Farbschema hat, kann er es einfach an einer Stelle ändern und das ändert dann alle relevanten Teile des Codes (da wir zB für die Playlist ja auch die Farbe Blau verwenden wäre diese auch von search&replace betroffen)
constexpr ist grundsätzlich eine Variable, dessen Wert zur Zeitpunkt des compilierens bekannt ist (gegenüber zB einem const, der zur Laufzeit 1x gesetzt wird). Das erlaubt es dem gcc diese Variable zu optimieren und bringt einiges an Vorteilen gegenüber einem Makro. zB Sichtbarkeit (#define ist im ganzen Code gültig über namespaces hinaus), Sicherheit bei einer Zuweisung.
Ein weiterer großer Punkt ist, dass constexpr dich zwingt sauberen C++ Code zu schreiben. ZB:
#define begin() x=4
#define end() x=17
[...] // viele Zeilen code
void x(){
int x = 33;
begin(); // begin verändert x ohne dass der Programmierer davon __hier__ etwas mitbekommt
printf("%d", x);
end();
}
// mit constexpr
constexpr int begin() {
return 4;
}
void x(){
int x = 33;
begin(); // hier hat begin keine Auswirkung auf x
[...]
}