Wie kann man einen bestimmten "sinnlosen Vergleich von Vorzeichen mit Null" Warnung stummschalten?

Question

Wie kann man einen bestimmten "sinnlosen Vergleich von Vorzeichen mit Null" Warnung stummschalten?

8

Angenommen, ich habe eine Funktion wie die folgende:

%Vor%

Angenommen, ich habe Warnungen richtig konfiguriert, wenn some_typedef sich als vorzeichenloser Typ herausstellt, erhalte ich eine Warnung, dass es einen sinnlosen Vergleich eines unsignierten Typs mit 0 gibt. Natürlich stimmt das, und es macht Sinn.

Nehmen wir jedoch an, dass ich tun möchte, dass die Überprüfung gegen Null aus einem oder mehreren möglichen Gründen im Code enthalten ist, beispielsweise:

Während die Grenzen immer Kompilierzeitkonstanten sind, könnten sie etwas sein, das sich ändern könnte (und die Makros könnten nicht sehr nah an der Funktion "leben"). Zum Beispiel können die Grenzen gesetzt werden, indem Optionen an den Compiler übergeben werden.
Ich möchte mich vielleicht gegen eine spätere Änderung des typedef zu einem signierten Typ wehren, da es möglich ist, dass jede Verwendung des typedefs bei der Änderung nicht genau untersucht wird.

Gibt es eine vernünftige, vernünftig tragbare Möglichkeit, die Warnung hier zum Schweigen zu bringen, ohne sie komplett auszuschalten?

Etwas, das auf einer 'STATIC_ASSERT ()' - ähnlichen Funktionalität (die mir zur Verfügung steht) beruht, wäre akzeptabel, wenn es sinnvoll ist. Ich bin OK mit dem Brechen des Kompilierens, wenn sich der Typ ändert, um jemanden zu zwingen, den Code anzusehen. Aber es ist vielleicht wichtig zu beachten, dass typeof nicht in allen Compilern verfügbar ist, auf die ich abziele.

Ich bin speziell auf der Suche nach Lösungen für die C-Sprache, so dass Vorlagen hier keine Verwendung finden ...

c warnings

Michael Burr 06.06.2011, 23:37

quelle

4 Antworten

Tags und Links c warnings

Django: Verwenden von Annotate, Count und Distinct in einem Queryset Wie kann die 32-Bit-Anwendung den Speicherort des 64-Bit-Programmverzeichnisses unter Windows Vista 64-Bit finden?

score 6 · Answer 1

~~Wenn some_typedef nicht als nicht signiert oder signiert bekannt ist, haben Sie ziemlich viel Pech.~~

Wenn Sie im Voraus wissen, dass some_typedef unsigniert ist, können Sie einfach

verwenden %Vor%

Oder Sie könnten in diesem Fall meine bevorzugte Version verwenden:

%Vor%

Bearbeiten: Ich nehme an, wenn some_typedef nicht als besonders signiert bekannt ist, dann müssen UPPER_BOUND und LOWER_BOUND beide positiv sein. Andernfalls hättest du sehr verrückte Ergebnisse von some_typedef bekommen, die zu unsigned befördert werden. So können Sie immer sicher verwenden:

%Vor%

score 2 · Answer 2

Das wird normalerweise von Pragmas kontrolliert. Für MSVC haben Sie #pragma warning und für GCC Sie haben Diagnose-Pragmas (die zugegebenermaßen keine genau definierte Kontrolle über Warnungen wie MSVC erlauben , aber das ist alles was du hast).

Bei beiden kann die Push / Pop-Mechanik nur die Warnungen für einige Codezeilen ändern.

score 1 · Answer 3

Ich habe mir eine ziemlich einfache und unkomplizierte Lösung ausgedacht. Das Kopieren der unteren Grenze in eine Variable bewirkt, dass der Compiler aufhört, sich zu beschweren:

%Vor%

Ich erwarte, dass der Compiler in einem optimierten Build immer noch in der Lage sein wird, den invarianten Vergleich zu entfernen (ich muss das allerdings verifizieren).

score 0 · Answer 4

Anstatt zu versuchen, die Warnung zum Schweigen zu bringen, warum nicht etwas dagegen tun und den Typdef vermeiden? Sie können Überladungen erstellen, um bestimmte Fälle zu behandeln, und indem Sie die Maskierung von Warnungen vermeiden, die expliziter erklären, dass Sie die Fälle behandeln, mit denen Sie zu tun haben. Meiner Erfahrung nach zwingt dies Sie dazu, neuen Code zu testen, statt Dinge zu maskieren, die in der Zukunft passieren könnten (wie plötzlich wechselnde Datentypen und dann mit Werten zu kämpfen, die auf mysteriöse Weise nicht in den erwarteten Bereichen liegen).