C / C++ Best Practices mit signierten / unsignierten Ints und Funktionsaufrufen

Ich stelle diese Frage für zwei verschiedene Sprachen: C und C++.

Was ist die beste Vorgehensweise beim Aufrufen von Funktionen, die eine entgegengesetzte Ganzzahlerwartung zu dem haben, was wir in unserem Code benötigen?

Zum Beispiel:

uint32       _depth;                        // uint32 = DWORD
int          depth;

_BitScanForward(&_depth, (uint32)input);    // DWORD, DWORD
depth = (int)_depth;

_BitScanForward erwartet DWORD (uint32) Parameter. Die Variable input ist vom Typ int16 und ich muss das Ergebnis verarbeiten _depth als int32 in meinem Code.

1. Muss ich mich um das Casting kümmern? input wie gezeigt? Ich weiß, dass der Complier es tun wird wahrscheinlich tun Sie es für mich, aber was ist die beste Vorgehensweise?
2. Ist es akzeptabel zu erklären _depth als int32 und vermeiden Sie daher, es anschließend wie gezeigt umzuwandeln?

HINWEIS:

Mein Kommentar zum Compiler basiert auf Erfahrung. Ich habe Code geschrieben, der ohne Warnungen in VS kompiliert wurde, aber bei der Ausführung abstürzte. Es stellte sich heraus, dass ich eine Funktion mit einer falschen Breite int aufgerufen habe. Also überlasse ich dieses Thema nicht mehr dem Compiler.

BEARBEITEN:

Die Antworten sind hilfreich, danke. Lassen Sie mich meine Frage präzisieren. Wenn es keine Breitenprobleme gibt, dh die Funktion erwartet kein schmaleres Int als das, was übergeben wird (wird offensichtlich fehlschlagen), ist es dann in Ordnung, sich auf den Compiler zu verlassen, um Zeichen- und Breitenunterschiede zu handhaben?

Ich würde dringend empfehlen, diese Funktion in einer benutzerdefinierten Wrapper-Funktion zu verstecken, die mit Ihrer bevorzugten API übereinstimmt (und innerhalb dieser Funktion das richtige explizite Casting durchzuführen). Im Fall der Verwendung von Compiler-spezifischen Funktionen hat dies den zusätzlichen Vorteil, dass es viel einfacher ist, es auf verschiedene Compiler zu portieren (sollten Sie das jemals tun wollen), indem Sie einfach diese Wrapper-Funktion neu implementieren.

Es ist sehr wichtig, eine explizite Umwandlung zu schreiben, wenn Sie von einem Integer-Typ ausgehen, der schmaler als ist int zu jedem ganzzahligen Typ, der die gleiche Breite oder breiter als ist int. Wenn Sie dies nicht tun, wird der Compiler es tun Erste Konvertieren Sie den Wert in int, wegen der “Integer Promotion”-Regeln und dann zum Zieltyp. Das ist fast immer falsch, und wir würden die Sprache nicht auf diese Weise entwerfen, wenn wir heute bei Null anfangen würden, aber aus Kompatibilitätsgründen bleiben wir dabei.

Vom System bereitgestellte Typedefs wie uint16_t, uint32_t, WORDund DWORD kann schmaler, breiter oder gleich groß sein wie int; In C++ können Sie Vorlagen verwenden, um es herauszufinden, aber in C können Sie das nicht. Daher möchten Sie möglicherweise explizite Umwandlungen für schreiben irgendein Konvertierung mit diesen.

Nun, es hängt irgendwie von Ihrer Verwendung usw. ab:

Wenn ich den benötigten Typ verwenden kann, verwende ich einfach den Typ.

Wenn nicht: Ihr Compiler sollte Sie in den Fällen warnen, in denen Sie Datentypen implizit konvertieren, was zu Über-/Unterläufen führen kann. Also habe ich diese Warnungen normalerweise aktiviert und ändere die implizite Konvertierung in explizite.

Da habe ich 2 verschiedene Ansätze:

Wenn ich mir zu 100% sicher bin, dass ich die Grenzen zwischen signed/unsigned int niemals über-/unterschreite, verwende ich static_cast. (normalerweise für die Konvertierung verschiedener APIs. Wie size() gibt int vs size_t zurück).

Wenn ich mir nicht sicher bin oder es möglich ist, bin ich jenseits der Grenzen, die ich verwende boost::numeric_cast. Dies löst eine Ausnahme aus, wenn Sie über Grenzen hinaus wirken, und zeigt somit an, wann dies geschieht.

Der Ansatz mit den Ausnahmen hält sich an die Praxis, hart zu versagen/abzustürzen/zu beenden, wenn etwas schief geht, anstatt mit beschädigten Daten fortzufahren und dann woanders abzustürzen oder andere Dinge mit undefinierten Daten zu tun.

Zuerst macht Ihr Compiler die Umwandlungen implizit und gibt Ihnen eine Warnung auf jeder sinnvollen Warnstufe.

Beide Umwandlungen, die Sie durchführen, sind Umwandlungen, bei denen der Compiler (oder Ihre Mitarbeiter) nicht einfach entscheiden können, ob sie korrekt sind, daher ist eine explizite Umwandlung oder explizite Konvertierung mit einem Begrenzungstest die beste Vorgehensweise. Welche Sie wählen, hängt von Ihrer Kenntnis der Daten ab. Am sichersten ist es, die Randbedingungen zu prüfen. Der billigste Weg ist einfach zu casten (in C++ verwenden Sie bitte static_cast und keine Casts im C-Stil).