Enum-Klasse
-
Öhm ja... ich hab da auch mal wieder eine Frage^^
Ist es möglich eine enum-klasse zu bauen, die ein Enum vollständig ersetzen kann?
Also anstatt
enum foo { bla, blubb, wub }eine Klasse zu nutzen.
Wenn ja, welche Operatoren müsste ich überladen, und würde sich die Klasse dann auch in switch-statements wie ein enum verhalten bzw. einsetzen lassen?
-
Vollständig ersetzen dürfte schwierig werden. Wozu brauchst du das überhaupt? (und was spricht dagegen, einen normalen enum zu verwenden?)
-
Möglich ist es. Den Sinn dahinter sehe ich jetzt auch nicht direkt (außer in Ausnahmen. Folgender modifizierter Code z.B. stammt aus einer Implementierung der Haskell-Prelude in C++):
struct Ordering { static Ordering const Lower; static Ordering const Equal; static Ordering const Higher; bool operator ==(Ordering const& other) { return m_value == other.m_value; } bool operator <(Ordering const& other) { return m_value < other.m_value; } private: Ordering(int value) : m_value(value) { } int m_value; }; Ordering const Ordering::Lower(-1); Ordering const Ordering::Equal(0); Ordering const Ordering::Higher(1);Um das Ding an die C++-Enums anzupassen müssten noch sämtliche Vergleichsoperatoren implementiert werden, außerdem braucht das Ding einen Konstruktor, der ein 'int' akzeptiert sowie einen 'operator int'. Hab ich was vergessen?
-
Konrad Rudolph schrieb:
Möglich ist es. Den Sinn dahinter sehe ich jetzt auch nicht direkt
enum heißt automatisch int. also typensicherheit zb?
einfach auf die enum classes warten...
-
queer_boy schrieb:
Konrad Rudolph schrieb:
Möglich ist es. Den Sinn dahinter sehe ich jetzt auch nicht direkt
enum heißt automatisch int. also typensicherheit zb?
Nicht wirklich. Unter C ist ein enum "nur" ein int, unter C++ sind das eigenständige Typen (die Vergleiche und implizite Umwandlung nach int zulassen).
z.B.:
typedef enum {red,green,blue} color; color c = red;//klappt int i = c; //klappt auch color c2 = i; //nur unter C erlaubt - unter C++ mußt du explizit casten
-
oh, das habe ich auch gar nicht gemeint, sondern die (un)möglichkeit, "hinter" einem enum etwas anderes als einen int zu haben. hab das nur erst am schluss dazu geschrieben, deshalb passt es vom sinn nicht ganz. das problem mit der impliziten umwandlung meinte ich mit typensicherheit.