Nochmal: vector vs map für Mapping
-
314159265358979 schrieb:
Dafür ist sowohl vector, als auch map falsch. Dafür nimmt man 2 rohe C-Arrays
Kommt immer drauf an.
Wenn du ein fixes mapping hast, ohne einfügen und löschen, dann reicht ein statisches C-Array mit den Schlüssel-Wert-Paaren (Wozu du da zwei Arays nehmen willst ist mir schleierhaft). Wers möchte kann das natürlich auch in ein std::array packen, aber das ist nur Syntax-Candy.
Wenn man Schlüssel-Wert-Paare einfügen/löschen möchte, braucht man entsprechend dynamische Strukturen, da sind rohe C-Arrays Blödsinn.Allgemein wäre ich mit solchen Absolut-Aussagen "Das ist falsch, das macht man anders" immer vorsichtig. Vor allem wenn die Rahmenbedingungen nicht genau feststehen.
Zum "einfacheren Zugriff" auf maps: kann man sich für statische Tabellen auch selber schreiben
-
Dass es Flags sind, impliziert eigentlich für mich, dass zur Laufzeit keine hinzukommen. Eine Methode mit einem einzigen Array habe ich gerade gezeigt, würde mich interessieren, wie du das gelöst hättest.
-
Die Flags sind natürlich statisch, die Texte erstmal auch. Aber bald hab ich vor das zu internationalisieren und dann sind die natürlich nicht mehr statisch. Wobei ich noch nicht sicher bin, ob man die Sprache live umstellen können soll.
Wieso nutzt Du im Code ein Makro für die Konstantendefinition? Tipparbeit ersparen?
Ansonsten geht log2 natürlich ganz gut... kann man ja sogar noch als Template implementieren.
-
Schreibfaulheit
Wenn du verschiedene Sprachen hast, dürfte das ebenfalls kein Problem sein. Dann steckst du die Arrays jeder Sprache nochmal in ein Array und gibst der Funktion für die Umwandlung als Parameter den Index des äußeren Arrays mit. Etwa so:#define DEFCONST(name, value) unsigned const name = value; // natürlich bin ich schreibfaul ;) DEFCONST(de, 0) DEFCONST(en, 1) #undef DEFCONST char const* const stringvals[][] = { { "foo", "bar" }, { "baz", "qux" } }; char const* flag_to_string(unsigned flag, unsigned lang) { return stringvals[lang][log2(flag)]; }
Wobei, für eine Sprache kannst du auch ein enum nehmen, wie auch immer. Ich bin mir gerade allerdings nicht sicher, ob MSVC schon enum classes unterstützt.
Nebenbei sollte die Funktion log2 wohl eher log2_minus_one heißen.
Mit enum class vielleicht so:
enum class language : unsigned { de = 0, en = 1, }; char const* flag_to_string(unsigned flag, language lang) { return stringvals[static_cast<unsigned>(lang)][log2(flag)]; }
-
Was fuer mieser C Frickelcode.
-
C++ler. schrieb:
Was fuer mieser C Frickelcode.
Was für ein dummer, falscher Kommentar
-
Ein globales char* array und Makros sind also guter C++ Stil? lol
-
Ob das Array global ist oder nicht, darauf habe ich mich in meinem Code nicht festgelegt. An einem Array aus char const* ist nichts verwerflich.
Makros sind nicht grundsätzlich böse. Es ist böse, sie für Funktionen zu missbrauchen, da das zu schwer findbaren Fehlern führt. Hier machen sie den Code sogar besser, da dadurch Redundanzen und damit auch mögliche Copy & Paste-Fehler beseitigt werden. Als netter Nebeneffekt ists auch weniger Tipparbeit und der Code wird besser wartbar, da nur an einer Stelle ausgebessert werden muss.
-
typedef unsigned int const flag_t; flag_t foo = 1; flag_t bar = 2; flag_t baz = 4; flag_t qux = 8;
-
Das ist aber immer noch weniger gut wartbar. Ein Flag muss keine Variable sein.
-
314159265358979 schrieb:
Das ist aber immer noch weniger gut wartbar. Ein Flag muss keine Variable sein.
Bitte was?
BTW: Was spricht gegen enums?
-
Michael E. schrieb:
Bitte was?
Ach, vergiss es. Sobald ich irgendwas sage, kommt bestimmt wieder gleich ein Unreg daher und versucht, wieder was falsches rauszulesen. Kein Bock mehr, meine Grundidee, wie mans mit den Arrays macht, ist rübergekommen.
Michael E. schrieb:
BTW: Was spricht gegen enums?
Nichts.
-
314159265358979 schrieb:
Ach, vergiss es. Sobald ich irgendwas sage, kommt bestimmt wieder gleich ein Unreg daher und versucht, wieder was falsches rauszulesen.
Man lernt mit der Zeit, die Deppen zu ignorieren.