Laden...

Hexadezimal-Konstante als int

Erstellt von Thomas123 vor 15 Jahren Letzter Beitrag vor 15 Jahren 2.933 Views
T
Thomas123 Themenstarter:in
25 Beiträge seit 2008
vor 15 Jahren
Hexadezimal-Konstante als int

Hallo,
eine Bibliothek gibt mir als Fehlercode einen int-Wert.
In der Dokumentation sind die Fehlercodes mit Hexadezimalwerten beschrieben, also z.B.
0x80040211 -> Verbindungsfehler.

Jetzt will ich den Fehlercode in einer switch-Anweisung auswerten:


switch (Error)
{
    case 0x80040211:
        Console.WriteLine("Verbindungsfehler");
        break;
.
.
.

Jedoch bekomme ich die Meldung:

Fehler 2 Der Typ "uint" kann nicht implizit in "int" konvertiert werden.
Es ist bereits eine explizite Konvertierung vorhanden. (Möglicherweise fehlt eine Umwandlung.)

Warum ist eine Hex-Zahl uint? Ich gebe doch hier das reine Bitmuster an, das ist zumindest in C/C++ so.
Ein Convert.ToInt32 geht nicht, da hinter dem case eine Konstante erwartet wird.

Gibt es noch eine andere Möglichkeit?

Gruß
Thomas

5.658 Beiträge seit 2006
vor 15 Jahren
case (int)0x80040211:

Evtl. ist ja auch die Variable "Error" gemeint?

// Edit:

Ich nehm alles zurück. Diesen Wert kannst du nicht in einen Int32-Wert umwandeln, da er zu groß dafür ist (größer als Int32.MaxValue). Hab grad keine Ahnung, was meine Umwandlung machen würde, evtl. wird daraus aber einfach ein negativer Wert gemacht. Mußt du mal ausprobieren.

Weeks of programming can save you hours of planning

T
Thomas123 Themenstarter:in
25 Beiträge seit 2008
vor 15 Jahren

Also wenn ich mir den Wert mit Console.WriteLine ausgeben lasse, wird
-2147220975
angezeigt.
Zumindest der Windows-Rechner gibt mir als Hexadezimalwert dafür:
0xFFFFFFFF80040211
aus.

In der Dokumentation ist auch ein Fehler, dort ist Error nämlich als long deklariert, aber die Bibliothek gibt wirklich nur einen int.

49.485 Beiträge seit 2005
vor 15 Jahren

Hallo Thomas123,

In der Dokumentation ist auch ein Fehler, dort ist Error nämlich als long deklariert, aber die Bibliothek gibt wirklich nur einen int.

trotzdem sollte case 0x80040211**L**: helfen.

herbivore

T
Thomas123 Themenstarter:in
25 Beiträge seit 2008
vor 15 Jahren

Hilft auch nicht wirklich.
Test:


int intVal = -2147220975;
long longVal = 0x80040211L;
Console.WriteLine("intVal = " + intVal);
Console.WriteLine("longVal = " + longVal);

long longVal2 = Convert.ToInt64(Error);
Console.WriteLine("longVal2 = " + longVal2);


Ausgabe:


intVal = -2147220975
longVal = 2147746321
longVal2 = -2147220975

Mit dem "L" hinter der Konstante kann ich im switch keinen Int angeben, ein Cast mit (int) vor der Konstante funktioniert ebenfalls nicht.

5.658 Beiträge seit 2006
vor 15 Jahren

Hallo Thomas123,

In der Dokumentation ist auch ein Fehler, dort ist Error nämlich als long deklariert, aber die Bibliothek gibt wirklich nur einen int.
trotzdem sollte case 0x80040211**L**: helfen.

herbivore

Müßte meiner Meinung nach 0xFFFFFFFF80040211L heißen.

Gibt es noch eine andere Möglichkeit?

Klar:

switch ((uint)Error) // Wenn Error vom Typ int ist müßte es so gehen
{
    case 0x80040211:
        Console.WriteLine("Verbindungsfehler");
        break;
.
.
.

oder

switch ((long)Error) // Dann müßte es auf jeden Fall gehen
{
    case 0xFFFFFFFF80040211L:
        Console.WriteLine("Verbindungsfehler");
        break;
.
.
.

Schöne Grüße,
Christian

Weeks of programming can save you hours of planning

T
Thomas123 Themenstarter:in
25 Beiträge seit 2008
vor 15 Jahren

Klar:

switch ((uint)Error) // Wenn Error vom Typ int ist müßte es so gehen  
{  
    case 0x80040211:  
        Console.WriteLine("Verbindungsfehler");  
        break;  
.  
.  
.  

Mit einem

case (uint)0x80040211L:

funktioniert es dann auch letzendlich. Danke!

Warum ist das eigentlich so kompliziert? DIe Hex-Konstante hat doch 32 Bit, wieso kann man den Wertebereich nicht ausnutzen?

49.485 Beiträge seit 2005
vor 15 Jahren

Hallo Thomas123,

uint und int haben eben gerade nicht den gleichen Wertebereich. Deshalb ist ja eine Umwandlung erforderlich, die implizit sagt, dass es nur auf die Bitfolge ankommt und nicht darum welchen Wert sie repräsentiert.

herbivore

S
248 Beiträge seit 2008
vor 15 Jahren

Hallo,

In der Dokumentation ist auch ein Fehler, dort ist Error nämlich als long deklariert, aber die Bibliothek gibt wirklich nur einen int.

Ich vermute, dass es sich bei dem "long" um ein C long handelt, dass 32 bit groß sein kann. Das long aus C# wäre ein long long.

Wikibooks

Spo

3.971 Beiträge seit 2006
vor 15 Jahren

Kleiner Tip, wenn man den Problemen mit "wie groß ist es eigtl. der Typ Int oder Long" aus dem Weg gehen möchte, empfiehlt es sich System.Int32 oder System.Int64 direkt als Datentyp zu verwenden (statt des sprachenabhängigen Schlüsselworts). Jeder der den Quellcode ließt, weiß direkt bescheid wie groß der Datentyp ist, besonders Leute die aus C++, VB, Delphi usw. kommen.

Noch ein Hinweis,
wenn man sich strikt an CLS-Compliant halten möchte oder sogar muss, keine Uxxx-Datentypen (sowie noch ein paar weitere) verwenden sondern direkt den mit dem größeren Wertebereich. Näheres steht unter Writing CLS-Compliant Code

Hallo Thomas123,
du kannst auch Error direkt als Int64 (long) deklarieren, ersparst du dir (unsinniges) casten.

Es gibt 3 Arten von Menschen, die die bis 3 zählen können und die, die es nicht können...