konstruktion, um aus einem union das "aktive" elemtnt zu kriegen.
-
Wenn dann müsstest du um diese Union eine struct oder class Packen, die diese Information bereithält.
-
Normal macht man das so:
enum CURRENT_ENUM (int_type, float_type); struct foo { union bar { int a; float b; } CURRENT_ENUM curr_type; }Und dann wird curr_type immer auf den aktuellen Typ gesetzt.
-
ja, da kam ich auch schon drauf, nu gefällt mir eines daran nicht: der code wird unglaublich lang...
wenn man nun das aktuell gesetzte elemnt haben will, muss mann immer folgendes schreiben:// ACHTUNG, nicht "kompilierbar" switch (foo_instance.curr_type) { case int_type: foo_instance.a // mach was damit break; case float_type: foo_instance.b // -"- break; }imo recht "unschön" und kompliziert.
gut, dann werde ich mal das problem wieder ein bisschen spezialisieren (bitte trotzdem noch posten
)
es geht mir egtl. garnicht darum, zugriff auf die member des unions zu bekommen, sondern auf deren member funktionen (natürlich nur die des aktuell gesetzten elements).
dazu hatte ich nun eine idee: da alle im union enthaltenen klassen die gleichen member funktionen haben, schreibe ich diese auch für das interface (die foo struct im letzten beispiel^^). in diesen methoden werden dann diese ellenlangen switchs gekapselt, und die entsprechende methode des zZ aktiven elements aufgerufen. ich hoffe ihr versteht mich...^^
aber vlt hat jemand noch ne bessere idee (kommt mir aber nicht mit vererbng, dass funzt bei meinem prob nich, bitte keine fragen
)
-
Ich glaub du willst das lieber mit OOP lösen und ne gemeinsame Basisklasse
definieren, von welcher alle abgeleitet sind und mit polymorphie für das aktuelle
Objekt die richtige Funktion aufgerufen wird.Wenn du damit nichts anfangen kannst, dann kauf dir auf schnellstem Wege das Buch "OOP für Dummies"
-
wie gesagt, polymorphie bringt hier nichts.
-
sry, muss nochmal nerven^^
ich habe in meiner oben vorgeschlagenen lösung ein problem:
der wrapper (die foo struct ^^) enthält natürlich ein union. wenn nun in einem der union member bzw. deren klasse eine member variable enthalten ist, bekomme ich den fehler c2621 (benutze vc++ .net 2003), die besagt, dass union member keine kopierkonstruktoren enthalten dürfen, warum spuckt er mir diesen fehler aus?? ich habe in der klasse, die im union steckt keinen copy ctor, die ganze klasse besteht zZ lediglich aus einer member variable...
-
das ist der fehler aus der msdn mal rauskopiert:
Compiler-Fehler C2621 Union 'Union' : Element 'Bezeichner' besitzt Kopierkonstruktor Das angegebene Element einer Union wurde mit einem Kopierkonstruktor deklariert. Union-Elemente dürfen keinen Kopierkonstruktor besitzen. Ein Beispiel für diesen Fehler: class A { A( const A& ); // A definiert Kopierkonstruktor }; union U { A a; // Fehler };er würde auch auftreten, wenn in der union zum bleistrift eine variable vom typ "string" aus der std steht.
ohne code schwer zu lokalisieren, welchen typ deine variable hat.
-
nur mal ein ansatz, er beruht zwar auf polimorphie, aber anders wirste es nicht ohne eine riesenmenge code hinbekommen:
struct StateInterface{ virtal void doSth(); }; //2 states class State1:public StateInterface{ //... public: void doSth(){...} }; class State2:public StateInterface{ //... public: void doSth(){...} }; //nun die Klasse,die verschiedene States haben soll class Test{ private: int state; std::vector<StateInterface*> stateHolder; public: Test():state(0){ stateHolder.push_back(new State1); stateHolder.push_back(new State2); } ~Test(){ for(int i=0;i<stateHolder.size();++i){ delete stateHolder[i]; } } void doSth(){ stateHolder[state]->doSth(); } void changeState(int i){ state=i; } };
-
so, nachdem ich ein bisschen mit boost gekuschelt hab, fiel mir die klasse variant auf. nachdem ich die doku auf boost.org über dieses thema größtenteils aufgesogen hab, hab ich mir ein eigenes kleines variant geschrieben (wirklich sehr klein, ohne die ganzen features, die boost bietet... aber für mich reichts^^) in kombination mit meiner zuletzt genannten idee klappt das gut, trotzdem danke an alle "antworter"^^
-
Könntest du, jetzt nachdem du die Lösung ja hast, uns verraten was du genau beabsichtigst?
-
öhm, nun gut, wenns sein muss^^
ich schreibe gerade eine lib für verschiedene dinge (strings, files, windows, grafik, input, sound, netzwerk, ........... bin aber grad erst angefangen^^).
da ich aber sehr entscheidungsUNfreudich bin, wusste ich nicht, wie ich die einzelnen komponenten implementieren sollte, zb für strings (woran ich gerade sitze^^), nehme ich TCHAR arrays oder doch lieber STL strings?? oder vlt sogar CString aus der MFC??? also habe ich erstmal alles implementier (jaja, klingt total krank, aber so bin ich...). nun wollte ich eine wrapper klasse, eine art interface, um zb funktionen, die beispielsweise strings als parameter annehmen jede erdenkliche implementation übergeben zu können. klar wäre am naheliegensten polymorphie, aber damit hatte ich schon probleme, nicht weil ich es nicht kann/versteh, sondern weil das einfach nicht funktionierte (kompliziert^^), also versuchte ich es mit unions. klassen in einem union dürfen aber keine selbst erstellten ctors, copy ctors oder dtors(?) haben, also musste ich mir eine (nach dem vorbild von boost::variant geschriebene, aber furchtbarfurchtbarfurchtbarfurchtbarfurchtbarfurchtbar vereinfachte) eigene "union klasse schreiben"
SO, das ist mein plan, und jetzt beschimpft mich oder werft mit steinen und chimpansenkot nach mir
-
nehme ich TCHAR arrays oder doch lieber STL strings?? oder vlt sogar CString aus der MFC???
wenns was eigenes soll, char-arrays, wenns einfach&gut sein soll string, und wenns nur mit VC++ zu benutzen sein soll,dann CString.
hmm.. also ich weis, was ich benutzen würde :D.
zum Thema Entscheidungen:
Andrei Alexandrescou schrieb:
Das Design von Software Systemen ist eine schwierige Aufgabe,weil ständig Entscheidungen getroffen werden müssen,und wie im normalen Leben fällt auch beim programmdesign das Entscheiden nicht immer leicht
Erfahrene Software-Designer wissen,welche Entscheidungen ein gutes Design garantieren.Der Anfänger steht bei jeder Designentscheidung im Luftleeren Raum.Ein erfahrener Designer ist mit einem guten Schachspieler vergleichbar,der mehrere Züge vorrausschauen kann. Das lernt er aber erst im Laufe der Zeit
[...]
Dem Neuling erscheint das ganze wie ein Puzzle und die kombinatorische Vielfalt der Designvarianten ist ein Hauptproblem für die Entwickler von Bibliotheken.kurz gesagt: wenn du nicht bereit bist entscheidungen einzugehen, wird deine Bibliothek als projekt scheitern. Unions zu benutzen, um die mangelnde entscheidungsfreudigkeit zu kompensieren ist so ziemlich das schlechteste was man machen kann. Wenn man dein String beispiel betrachtet, hat man da so eine art überaschungsei. man kann sich auf keinen typ wirklich einstellen, weil jede andere funktion die Union anders mit werten bestücken könnte. Das hauptproblem ist aber,dass diese 3 von dir genannten Stringtypen vom Funktionsumfang nicht kohärent sind, dh die chance, dass eine funktion zuerst die typen konvertieren müsste ist hoch,die chance, dass sich das auf dauer auf die geschwindigkeit,die wartbarkeit, die lesbarkeit und die funktionalität auswirkt auch.
