Zitat Zitat von Brother John Beitrag anzeigen
Einige Variblen deklarierst du am Funktionsanfang. Das kenne ich eher aus uraltem C-Code. Nachteil ist, dass notfalls uninitialisierte Variablen in einem viel größeren Scope verfügbar sind als nötig. Deswegen versuche, die Variablen idealerweise zusammen mit der ersten Verwendung zu deklarieren.
Mhm, okay, kann ich nachvollziehen. Ich dachte halt, dass es so übersichtlicher wäre. Aber dann bau ich das entsprechend um.

Zitat Zitat von Brother John Beitrag anzeigen
[*]sConv – ist unbenutzt, schau mal auf deine Compilerwarnungen.[*]strTmp – kann sterben. Du kannst im switch direkt an strResult anhängen.
sConv hatte ich ja zuvor in Benutzung. Aber jetzt natürlich nicht mehr, dann kann das raus, da hast du Recht.

Zitat Zitat von Brother John Beitrag anzeigen
Die Potenzierung kann immer noch schief gehen. Dieser Ausdruck:
[...]
Richtig. Es war offenbar nur Glück, dass ich da bisher keine Fehler deswegen hatte. Oder aber die haben da bei Code::Blocks wirklich was an der Implementierung von pow() geändert. Wie dem auch sei, llround() ist so oder so ein guter Hinweis, das braucht man ja immer mal.

Zitat Zitat von Brother John Beitrag anzeigen
Btw: Bitte nie den klassischen C-Cast verwenden – also sowas wie (long long)foo –, denn der führt nicht zu einem Compilerfehler, auch wenn der Cast Unfug ist. Die C++-Casts sind immer besser: meistens static_cast<>, bei polymorphen Objekten auch mal dynamic_cast<>. Selten braucht man für Byte/Bit-Schubsereien auch mal reinterpret_cast<>. Aber Vorsicht damit: Das ist der, der die Compilerchecks abschaltet. Und Finger weg vom const_cast<>!
Und auch das ist natürlich ein super Tipp. In dem Buch, aus dem ich lerne, sind beide Formen (also der C- und der C++-Cast) aufgeführt, allerdings hatte ich sie dort als einigermaßen gleichwertig verstanden. Und die alte Variante ist natürlich weniger Schreibarbeit Aaaber dann steige ich jetzt um auf die aktuellere Form

Zitat Zitat von Brother John Beitrag anzeigen
Zum Algorithmus selbst hat Roin schon in #4 eine feine Vereinfachung gepostet. Ich stell noch eine Implementierung daneben, die die Sache aus einer ganz anderen Richtung angeht.
Okay, den Codeschnipsel habe ich jetzt zwar vom Ansatz her verstanden, aber das ist glaube ich noch zu hoch für mich. Die Bit-Operatoren kommen später noch, soweit ich weiß

Zitat Zitat von Brother John Beitrag anzeigen
Wie aktuell einen Error-State für ein ganzes Objekt würde ich jedenfalls vermeiden. Das kommt der globalen Error-Variable aus C recht nahe, und die ist notorisch fehleranfällig.

Noch zwei technische Sachen: Gruppen von const short als Flags zu verwenden, ist auch eher ein Pattern aus altem C. In C++ gibt’s dafür enum class. Komplette Großschreibung sollte man ausschließlich für Makros reservieren. Es gibt zwar die – aus meiner Sicht – Unsitte, Konstanten und Enumeratoren groß zu schreiben, aber das clasht früher oder später mit irgend einem Makro – v.a. beliebt unter Windows – und führt zu grauen Haaren und Heiserkeit vom vielen Fluchen.
Mhm, okay... Dann gucke ich mir dafür vielleicht doch die Exceptions an. Ich denke nochmal drüber nach.
Die Enumerations kenne ich prinzipiell schon. War dann nur doch zu faul, die zu nutzen Baue ich dann auch noch um. Allerdings schreibt der Autor meines Buches tatsächlich, dass eine Konvention ist const-Bezeichner groß zu schreiben. Ist vielleicht auch einfach Geschmackssache, oder aber er kommt noch aus einer anderen Zeit, wo das üblicher war oder so.

--- [2018-09-11 20:24 CEST] Automatisch zusammengeführter Beitrag ---

So, ich glaube, ich habe soweit alles eingearbeitet. Mensch, da lerne ich ja noch richtig was
Habe leider eben festgestellt, dass für die Umwandlung von und in binär selbst der unsigned long long eher klein ist. Vielleicht sollte ich dafür doch String verwenden. Da überlege ich nochmal.

Vielen Dank auf jeden Fall schon für eure ganzen Ratschläge! Ist gut zu wissen, dass hier einige C++-Nasen an Board sind. Ich komme bestimmt mal wieder auf euch zurück