c++ enum auf ein unsigned int-Vergleich

Fand ich dies in den code arbeite ich im moment und dachte, es war die Ursache für einige Probleme, die ich habe.

In einen header irgendwo:

enum SpecificIndexes{
    //snip
    INVALID_INDEX = -1
};

Dann später - Initialisierung:

nextIndex = INVALID_INDEX;

und verwenden

if(nextIndex != INVALID_INDEX)
{
    //do stuff
}

Debuggen Sie den code, der Werte in nextIndex nicht so Recht Sinn (Sie waren sehr groß), und ich fand, dass es erklärt wurde:

unsigned int nextIndex;

So, die erste Einstellung INVALID_INDEX war underflowing unsigned int, und wenn er auf eine große Anzahl. Ich vermutete, dass war, was das problem verursacht, aber schaut man genauer hin, ist der test

if(nextIndex != INVALID_INDEX)

War richtig verhält, ich.e, es nie ausgeführt die Körper der wenn nextIndex war der "große +ve-Wert".

Ist das richtig? Wie ist das passiert? Ist der enum-Wert, der als implicately cast zu unsigned int denselben Typ wie die variable, und damit wird gewickelt in der gleichen Weise?

Cheers,

xan

ITYM "Dann später - asssignment". Initialisierung wäre unsigned nextIndex = INVALID_INDEX

InformationsquelleAutor | 

  1. 11

    Ja alles.
    Gültig ist der code, es wird auch Häufig verwendet, Bibliothek-Seite C++ - code, in modernem C++ (es ist seltsam, wenn man es das erste mal, aber es ist ein sehr Allgemeines Muster in der Realität).

    Dann enums sind signed ints, aber Sie bekommen implizit umgewandelt in unsigned ints, jetzt diese je nach compiler geben könnte, eine Warnung, aber seine immer noch sehr Häufig verwendet, allerdings sollten Sie explizit casten, um es klar zu Betreuer.

    Ich herzlich widersprechen. Erstens ist dein code sagt, dass nextIndex ist nicht, wenn in der Tat ist es nicht irreführend für den Leser. Zweitens, wenn Sie sich später dafür entscheiden, fügen Sie neue, positive Werte zu SpecificIndexes und Operatoren > oder < für Prüfungen, nichts.
    enums sind unterzeichnet, aber Sie sind Recht über die > < Betreiber vermasseln, wie zum Beispiel, wenn Sie Sortieren Sie Sie in einen Behälter. Aber eine gute Bibliothek würde in diesem Fall behandeln sicher, oder lassen Sie, fügen Sie ein invalidIndex dem container in den ersten Platz. Sowieso sehen Sie Sachen wie diese auch im Schub...
    Ja, dies ist ein problem, das ich zu finden bin. Funktionen, die die Nutzung nextIndex Behaupten, dass es > 0, so verändert es ein signed int ist keine triviale option, und anderen code, ich glaube stützt sich auf die Art und Weise es umgesetzt wurde. Es ist eher verwirrend.
    riecht nach Zeit umgestalten zu mir 🙂 Jedenfalls eine schnelle Lösung ist Assert(index - >0 && index != INVALID_INDEX); Das ist korrekt, zumindest und lässt die Geltendmachung besser dokumentieren zu können.

    InformationsquelleAutor

  2. 2

    enums kann dargestellt werden, indem Sie signiert oder unsigniert sind Integrale Typen, je nachdem, ob Sie enthalten keine negativen Werte, und was der compiler wie sich das anfühlt. Hier das Beispiel enthält einen negativen Wert, und daher muss dargestellt werden durch eines signierten ganzzahligen Typ.

    Geschlechter-Vergleich zwischen signed und unsigned Typen ist sicher und in der Regel nicht, was der Autor beabsichtigt, den Wert mit Vorzeichen umgewandelt in unsigned erste, und das Ergebnis des Tuns, die definiert ist durch den C++ - standard und ist intuitiv (zumindest ist es sobald Sie wissen, den Typ der destination. Außer vielleicht, wenn Ganzzahlen, die die beiden nicht ergänzen. Also, vielleicht nicht ganz so intuitiv, aber es funktioniert in der Regel nicht zu Problemen führen).

    Bestellen Vergleich ist eher zu Fehlern führen. Zum Beispiel:

    SpecificIndexes value = INVALID_VALUE;
return (value >= 0);

    gibt false zurück, aber:

    unsigned int value = INVALID_VALUE;
return (value >= 0);

    gibt true zurück. Manchmal ist der Autor nicht den Unterschied schätzen, vor allem, wenn die Art der "Wert" nicht ganz so offensichtlich zum Zeitpunkt der Verwendung. Der compiler kann auch warnen, etwa im zweiten Beispiel, obwohl, weil (value >= 0) ist eine Tautologie.

    InformationsquelleAutor

  3. 1

    In der Tat, -1 ist implizit umgewandelt, um seine equivalente unsigned-Wert, wenn es zugeordnet ist nextValue. Die equivalente unsigned ist der Wert, mit dem gleichen bitweise Darstellung (das ist 111111111111..., dies ist der maximale Wert ohne Vorzeichen).

    Später auf, im Vergleich Anweisung, eine weitere implizite cast passiert.

    Also das funktioniert jetzt, aber kann dazu führen, problem in der Zukunft. Es ist nie eine gute Idee, mix-signed-und unsigned-Werten.

    Und was ist mit dem test mit dem enum-Wert, ich gehe davon aus, dass die einen impliziten cast zu?
    Nur für das Protokoll, ich vereinbarte mit xan ' s point und editiert meinen Eintrag entsprechend. Aber ich weiß nicht, warum mein Kommentar verschwunden ist.
    "Das entspricht unsigned ist der Wert, mit dem gleichen bitweise Darstellung" - dies ist true, wenn die Implementierung verwendet zwei-Komplement-Darstellung für signed integral types. Aber es ist nicht die definition, und ist nicht wirklich für einer-Komplement oder Vorzeichen-Wert-Darstellungen. Die sind sowieso selten.

    InformationsquelleAutor

  4. 0

    Ja, ich glaube, enums sind unterzeichnet. Ändern 

    unsigned int nextIndex;

    zu 

    int nextIndex;

    und das Programm sollte funktionieren.

    Es funktioniert wie es ist (es ist ein Teil eines bestehenden Systems, nicht etwas, das ich Schreibe, von Grund auf) - meine Frage war, warum es funktionierte, wie Sie es Tat, wie es aussah, sehr falsch!

    InformationsquelleAutor

  5. 0

    Den C++ - standard erlaubt es, eine Implementierung zu verwenden, eine signierte Typ für enums, aber nicht erforderlich. Deshalb können Sie im Allgemeinen davon ausgehen, dass es ist sicher zu stellen, dass negative zahlen in enum.

    InformationsquelleAutor

Schreibe einen Kommentar