Hallo,
ich habe folgenden VBA Code:

in C# so geschrieben:


und bekomme jetzt die Fehlermeldung:

Zitat:

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

bei

Erhalte ich die Fehlermeldung:

Zitat:

Fehler 1 Der Konstantenwert "2164260865" kann nicht in "int" konvertiert werden. (Verwenden Sie zum Überschreiben die unchecked-Syntax.)

Waere super wenn mir wer helfen koennte, weis echt nimma weiter

Moderiert von Christian S.: C#-Tags hinzugefügt

Deine Errorwerte(HRESULTs) sind größer als der von int darstellbare max. Wert. Deshalb interpretiert der Compiler die Werte als unsigned int die du dann selbst einer int Variablen zuweist. Das mag der Compiler nicht. Wen es unbedingt ein int Typ sein muß und kein unsigned int, solltest du den dem HRESULT entsprechenden negativen Dezimalwert zuweisen da es bei einem HRESULT eh nur auf das Bitmuster ankommt.

Also anstatt

0x81000043 nimm -2130706365
0x83001A03 nimm -2097145341

Müsste es nicht reichen, einen expliziten Cast zu benutzen?

Christian S. hat folgendes geschrieben :

Müsste es nicht reichen, einen expliziten Cast zu benutzen? markieren C#-Quelltext     1: public const int ERR = (int) 0x81000043;

Nein. Egal ob expliziter oder impliziter Cast der Wert bleibt zu groß für int.

Das ist mir klar Aber der explizite Cast sollte automatisch zu dem negativen int-Wert führen, was viel bequemer ist.

Da hast du recht. Das wäre bequemer. Macht der Compiler aber leider nicht.

Hab's gerade probiert, tatsächlich muss man noch ein unchecked einsetzen:


Da war ich wohl zu sehr den Oxygene-Compiler gewöhnt, der verlangt nicht das man einen expliziten Cast noch mal expliziter macht *g*

Dachte man könnte unsafe nur im Context einer Methode anwenden. Ist nicht wirklich schön, aber lesbarer als selbst umzurechnen ist es auf jeden Fall.

Ralf Jansen hat folgendes geschrieben :

Dachte man könnte unsafe nur im Context einer Methode anwenden.

unsafe ist wieder was Anderes . Eigentlich sollte dich der Compiler bei public const int ERR = (int) 0x81000043; auch auf unchecked hinweisen.
Und dass C# unchecked hier verlangt, finde ich gut, muss/sollte man schließlich im restlichen Code auch machen, wenn man einen Overflow zulassen will.

Kha hat folgendes geschrieben :

Und dass C# unchecked hier verlangt, finde ich gut, muss/sollte man schließlich im restlichen Code auch machen, wenn man einen Overflow zulassen will.

Ich find das überflüssig. Ich bekomme erst den Hinweis, dass uint nicht implinzit in int konveritert werden kann, aber eine explizite Konvertierung existiert. Und wenn ich die dann benutze, reicht das immer noch nicht (ich stelle mir hier ein lautes "Ätsch!" aus Richtung Compiler vor).

Wollen Sie uint in int konvertieren? - Ja
Wirklich? - Ja!
Sind Sie sich sicher? - Ja!!
Ganz sicher?
...

Christian S. hat folgendes geschrieben :

Kha hat folgendes geschrieben : Und dass C# unchecked hier verlangt, finde ich gut, muss/sollte man schließlich im restlichen Code auch machen, wenn man einen Overflow zulassen will. Ich find das überflüssig. Ich bekomme erst den Hinweis, dass uint nicht implinzit in int konveritert werden kann, aber eine explizite Konvertierung existiert. Und wenn ich die dann benutze, reicht das immer noch nicht (ich stelle mir hier ein lautes "Ätsch!" aus Richtung Compiler vor). Wollen Sie uint in int konvertieren? - Ja Wirklich? - Ja! Sind Sie sich sicher? - Ja!! Ganz sicher? ...

Man betrachte mal folgendes:


In beiden Zeilen wird dann - oh großes Wunder - beide Male dieselbe Zahl geschrieben - also insbesondere tritt keine Ausnahme auf (VS 2005).

Wenn ein Überlauf kritisch und es somit interessant sein könnte, zu unterscheiden, ob man ihn zulassen will oder nicht, dann
doch bei der Konvertierung von Variablen - dabei kann kommt es doch normalerweise zu den versehentlichen Überläufen.

Wenn das nicht zwischenzeitlich geändert worden ist (gerade kein VS 2008 zur Hand - kann das jemand bestätigen oder widerlegen?) , dann ist das unchecked wirklich unsinnig.

Aconcagua hat folgendes geschrieben :

In beiden Zeilen wird dann - oh großes Wunder - beide Male dieselbe Zahl geschrieben - also insbesondere tritt keine Ausnahme auf (VS 2005).

Nicht unbedingt, das hängt vom "/checked"-Switch ab.
Eigentlich ist das Konzept in sich völlig schlüssig: Ausdrücke, bei denen man einen Überfluss hinnehmen/verhindern will, umgibt man explizit mit unchecked/checked; den Rest des Codes stempelt man damit implizit mit "hier sollte eigentlich kein Overflow vorkommen" ab. Debuggt man nun mit /checked+, wird man auf alle weiteren Overflows hingewiesen, im Release-Build sind diese zusätzlichen Abfragen der Performance zuliebe verschwunden.
VS benutzt nun in den Standardeinstellungen leider selbst beim Debug-Build /checked-, womit der Sinn von unchecked schon ein wenig infrage gestellt wird. Aber nicht jeder benutzt die Mainstream-Settings, also immer schön unchecked benutzen, wenn man einen Overflow provozieren will .

Das Ganze geht aber eigentlich an der Diskussion vorbei , denn Konstanten werden ja zur Compile Time ausgewertet, da hat kein Compiler-Schalter Auswirkungen.

@Christian: Angenommen, ich habe irgendwoher (andere Assembly?) eine uint-Konstante, rechne damit ein bisschen herum und will es dann in einer int-Konstanten speichern. Und wundere mich dann, warum ein negativer Wert herauskommt... und was das gerade für ein realistisches Beispiel ist [*]. Nunja, "ich will nen anderen Typ" und "bitte ohne Warnanlage" sind aber einfach zwei verschiedene Aussagen an den Compiler, zur Compile- und zur Runtime. So .

[*]Genauso realitätsfern wie imho das gesamte Thema . Overflow in Konstanten... ich bin immer davon ausgegangen, dass man uint-Werte am besten in uint-Konstanten speichert .