Warnungen 3rd-Party abschalten?

TorDev

Hallo,

ich arbeite mit Visual Studio 2022 gerade an einer OpenGL Bibliothek. Ich versuche immer alle Warnungen zu beachten, aber bei 3rd-Party Software (z.B. glm) macht es keinen Sinn.

Ich habe im Netz gesucht, und soll lt. einem StackExchange-Eintrag unter "C/C++ -> External Include" nachschauen. Ich habe folgendes eingestellt:

External Header Warning Level: Turn Off All Warnings (/external:W0)
Disable Code Analysis for External Headers: Yes

Die Warnungen kommen aber noch immer, was mich relativ stört. Weiß jemand eine Lösung?

Danke im Voraus

VG Torsten

Quiche Lorraine

@TorDev
Hast du auch die Optionen für die aktuelle Konfigurationen eingestellt?

Passiert mir öfters dass ich etwas für Release konfiguriere aber mit Debug kompiliere.

TorDev

G' Morgen,

ich weiß, was du meinst Aber in diesem Falle, habe ich das mal beachtet.

Aber mir fällt da ein anderes Argument ein, woher soll Visual Studio wissen, was "externe Includes" sind? Wie muss ich ihm das denn mitteilen?

VG Torsten

DNKpp

@TorDev sagte in Warnungen 3rd-Party abschalten?:

Aber mir fällt da ein anderes Argument ein, woher soll Visual Studio wissen, was "externe Includes" sind? Wie muss ich ihm das denn mitteilen?

Vielen Compilern kann man das explizit mitteilen. Für clang z.B. übergibt man include-directories mittels -i option und "externe includes" mittels -isystem. In der Regel übernimmt das dein Buildsystem und das muss entsprechend konfiguriert werden.
Ich benutze echte VS-Solutions nur sehr spärlich allerdings gibt es glaube ich auf der ersten Settings-Page ein Feld, in welchem man externe include-dirs explizit auflisten kann.

Quiche Lorraine

@TorDev sagte in Warnungen 3rd-Party abschalten?:

Ich versuche immer alle Warnungen zu beachten, aber bei 3rd-Party Software (z.B. glm) macht es keinen Sinn.

Mal einen Schritt zurück. Warum kommen da überhaupt Warnungen?

Eigentlich müsstest du doch die 3rd-Party Software (z.B. glm) bauen können. OK, da werden sicherlich die ein oder andere Warnung kommen. Aber das macht man einmal und gut iss.

Und danach bindest du die LIB oder DLL einfach nur noch ein. Da sollten also keine Warnungen von der 3rd-Party Software kommen.

BTW:
Warnungen abschalten hat auch so seine Tücken, da ich dadurch den folgenden Fehler gefunden habe:

if (fabs(Value - Mid > Border))

Th69

@TorDev sagte in Warnungen 3rd-Party abschalten?:

Aber mir fällt da ein anderes Argument ein, woher soll Visual Studio wissen, was "externe Includes" sind? Wie muss ich ihm das denn mitteilen?

Bei den Konfigurationseinstellungen des Projekts unter VC++ Directories: General: External Include Directories.

TorDev

Guten Morgen,

@Quiche-Lorraine Die glm-Bibliothek ist Vektor- und Matrizenrechnung, in meinem Fall für OpenGL. Das ist ein Header-only Projekt
Ich weiß natürlich, dass das "gefährlich" sein kann, ich bin auch kein Freund davon - wie ich oben bereits schrieb. Ich muss mal gucken, wie ich voran komme, eine Möglichkeit wäre natürlich, das Zeug nach zu programmieren - zumal ich nicht ansatzweise alles benötigen werde.

@Th69 Danke, das hat geholfen

VG Torsten

Finnegan

@TorDev Über Kommandozeilenparameter ist mir nur bekannt, dass man damit bei gängigen Compilern für jeweils einzelne Translation Units Warnungen ausschalten kann. Ich gehe stark davon aus, dass auch die Einstellungen im VS-Projekt nur eben das ermöglichen. Bei einer Header-Bibliothek muss man das m.E. im Code machen, wenn davon nicht auch der Rest des Codes betroffen sein soll. Für MSVC z.B. wie hier beschrieben. Das könnte dann z.B. so oder ähnlich aussehen:

#ifdef _MSC_VER
    #pragma warning(push)
    #pragma warning(disable : 4705)
    #pragma warning(disable : 4706)
    #pragma warning(disable : 4707)
#endif

#include <library.h>

#ifdef _MSC_VER
    #pragma warning(pop)
#endif

Das hat allerdings den Nachteil, dass damit nur Warnungen unterbunden werden, die direkt beim Parsen des Headers auftreten. Wenn die Lib viele Templates verwendet und die Warnungen erst bei der Template-Instanziierung kommen, wird das nicht helfen. Dann bliebe nur noch jede betroffene Instanziierung in deinem Code in so eine Präprozessor-Logik zu verpacken.

Das wäre mir dann allerdings zu viel extra "Müll" im Code. Da würde ich entweder mit den Warnungen leben oder mich sogar darum bemühen, dass diese nicht mehr auftreten. D.h. ich würde diese Bibliothek vielleicht sogar fixen und dem Projekt als Pull-Request zur Verfügung stellen (dann allerdings auch sicherstellen, dass das auch mit GCC und Clang keine Warnungen erzeugt oder meine Lösung nicht sogar neue generiert).

Für viele Warnungen bedarf es auch keine Änderung an der Semantik, sondern man muss im Code lediglich explizit machen, dass das so gemeint war.