mir fällt auf, dass ich - seit ich C++ ein wenig besser kenne - triviale Dinge unglaublich kompliziert und durchdacht löse, sodass ich viel zu viel Zeit für Unwesentliches investiere. Beispielsweise habe ich letztens Tage investiert für eine einfache Color-Klasse. Ihre Vorzüge:
- Für nichts Speicher bezahlen was man auch nicht braucht (wenn jemand 5 Bit pro RGB-Komponente will bekommt er es (in 16 Bytes)), ebenso für den Alpha-Kanal
- Typen der Komponenten frei wählbar
- Überladung der Container für Farben mit <8 Bits (z.B. Monochrom) damit man weniger Speicher braucht
- Traits für den Wertbereich der Komponenten, sodass man auch float-Farben haben kann, deren Wertebereich -1..3,972 ist
- Implizite Konvertierbarkeit zwischen verschiedenen Typen / Traits
- Verschiedene Modelle, sodass man nicht immer zwischen HSV/RGB umrechnen muss sondern sie wahlweise auch dauerhaft so speichern kann.

Heute als ich die Klasse dann anwenden wollte hab ich sie aus Frust weggeworfen und stattdessen einfach ein struct mit 4 uc's genommen...

Wenn ich etwas neues zu programmieren beginne, dann durchdenke ich mir unglaublich lang das Design, solange bis mir kein einziger Fall mehr einfällt, in welchem das Design nicht optimal ist. Das endet meistens in Konstrukten mit 5 oder mehr Template-Parametern und xy Helferklassen.

Geht / ging es sonst noch jemandem so? Wie kommt man davon wieder los? Ich will doch nur flexiblen Code schreiben...

MfG

Ja, so in die Richtung denkend erwische ich mich auch öfters. Der Trick ist, zu erkennen wann man wie viel Abstraktion braucht und wann sie sinnlos ist.

Ich hatte das letztens erst wieder gelernt. Allgemeine SPI + USB Funktionen -> spezifische Protokollfunktionen, die die allgemeinen SPI/USB-Funktionen benutzen -> Allgemeine "Initialisier mal"-Funktion, die die Protokollfunktionen benutzt. Da sollte jeder Anwender das richtige Level finden.

Außerdem sollte man bei der Implementation der Color-Klasse nicht jede Möglichkeit korrekt implementieren, sondern die Klasse erweiterbar halten. 4 unsigned chars sind als Templatespezialisierung implementiert, die komprimierte 5 Bit Variante wird implementiert sobald sie jemand braucht (sprich nie).

Ich meine man fährt damit ganz gut solange man keine Libraries designen muss, aber ich habe damit nicht genug Erfahrung um sagen zu können, dass es nicht noch besser geht.

Eine Klasse zu machen ist gut, aber übertreibs nicht mit den Template-Parametern. Im Grunde kannst du alles über Traits auslagern, aber irgendwann ist es dann doch einfacher, gleich eine neue Klasse zu schreiben.

Vermeide ausserdem monolithische Klassen. Speicher komprimieren? bitfield<5, 5, 5, 5>, welches auf std::bitset basiert. Color-Klasse? Hat den Farb-Container als Template-Parameter, entweder std::array<unsigned char, 4> oder bitfield<5, 5, 5, 5>. Wenn jede Klasse nur einem kleinem Aufgabenbereich hat, fällt es viel leichter, einzelne Klassen neu zu schreiben.