Compiler-Warnungen in C ++: accept können nicht abgelehnt werden

    Wir gingen einmal in Cloud4Y über die Programmierung in der Cloud zu sprechen und auf welcher Programmiersprache kann mit Recht der in Betracht gezogen werden „Wolke“ . Wie lange es gedauert hat, diskutierten sie über die Fehler der Texter - über ihre doppelte Natur: Sie können nicht alles ignorieren und auf alle achten - Sie werden nicht lange darüber nachdenken. Heute präsentieren wir Ihnen ein kleines Skript für den Umgang mit Warnungen des Compilers, mit dem Sie einen groben Fehler nicht übersehen und das Nervensystem in Ordnung halten können.


    Bild

    Es werden häufig Compiler-Warnungen zu Teilen des Codes angezeigt, die potenzielle Probleme oder fehlerhafte Stile aufweisen. Manchmal verweisen sie auf Code, der wirklich nicht funktioniert, also ignorieren Sie sie nicht.


    Wahrscheinlich haben Sie beim Kompilieren von C ++ - Code ein oder zwei Compiler-Warnungen gesehen . Wenn Sie an einem Großprojekt arbeiten, sehen Sie täglich Hunderte solcher Warnungen, und nach einer Weile werden einige davon Ihnen bekannt. Sie kennen sie nicht mehr nur, sie werden zu störenden Hintergrundgeräuschen, die auftreten, wenn Sie mit dem Kompilieren beginnen.


    Ignorieren Sie keine Compiler-Warnungen


    Natürlich können diese Warnungen nur ärgerlich sein; Darüber hinaus entstehen sie meistens für perfekt funktionierenden Code, der definitiv keine Fehler enthält.


    Stellen Sie jedoch sicher, dass eine von mehreren tausend Compiler-Warnungen wirklich Sinn macht. Manchmal schreiben wir Code, der kompiliert, aber  etwas funktioniert nicht wie erwartet. Wie kann man also im Namen von Habr feststellen, welche Warnung auf einen echten Fehler hinweist? Wie kann man es von Hunderten anderen unterscheiden, für die der Code gültig ist? Muss man wirklich so viel Zeit damit verbringen, sie alle zu lesen? Es ist fast unmöglich.
    Akzeptieren Sie die Richtlinie "Keine Warnung"


    Um ganz ehrlich zu sein, können Sie mit Compiler-Warnungen nur zwei Dinge tun: Ignorieren Sie sie oder entfernen Sie sie. Wenn Sie sie ignorieren, werfen Sie ein Werkzeug in den Papierkorb, um Fehler zu vermeiden. Stimmen Sie zu, bei einem oder zwei schwerwiegenden Fehlern mit den Fingern nachzuschauen? Wahrscheinlich nicht.


    Sie können sagen, dass Sie damit leben können, wenn es nur wenige Compiler-Warnungen gibt. Hier ist die Sache: Sie überprüfen Ihren Code wahrscheinlich relativ oft (zumindest hoffen wir das). Dies bedeutet, dass Sie häufig kompilieren müssen und dies Compiler-Warnungen mit sich bringt. Sie werden anfangen, auf sie zu achten. Sie können immer noch auf sie achten, wenn Sie 6 Warnungen anstelle von 5 erhalten; aber wirst du den 11. bemerken  ? Der 20. ? 52. ?
    Warnungen loszuwerden ist die einzig akzeptable und sichere Option für die Psyche.


    Ändern Sie Ihren Code, um Warnungen zu entfernen


    Obwohl wir manchmal möchten, dass der Compiler eine bestimmte Warnung einfach ignoriert, ist es besser, nur den Code zu ändern. Wenn der Code für den Compiler nicht klar ist, besteht die Möglichkeit, dass er auch für den Menschen nicht verständlich ist.


    Oft reicht es aus, Ihre Absichten im Code zu klären, um den Compiler zum Schweigen zu bringen. Einige Compiler geben möglicherweise Hinweise zum Beheben bestimmter Warnungen. Werfen wir einen Blick auf die häufig auftretenden Zuweisungswarnungen in einem bedingten Kontext:


    Bild

    Für Clang sieht es so aus:


    Bild

    Der zweite Fall, der dieser Warnung zugrunde liegt: Manchmal schreiben wir a = b, wenn wir a == b im Sinn hatten.


    Während andere Compiler lediglich warnen, dass die von uns geschriebene Aufgabe in diesem Codeabschnitt ziemlich seltsam aussieht, versucht CLANG hilfreich zu erraten, was wir meinen könnten.


    Der erste Zeiger zeigt uns einfach, wie die Warnung behoben werden kann, wenn die Aufgabe tatsächlich beabsichtigt war. GCC hat die gleiche Warnung und den gleichen Vorschlag, den es zu beheben gilt, ohne jedoch eine Alternative anzugeben:


    Bild

    Viele bevorzugen CLANG, da wir so die richtige Lösung erraten können. Dies ist viel besser, da es möglich ist, einen Fehler im Code zu finden, der nicht auftreten würde. Wir akzeptieren automatisch alles, was der Compiler anbietet.


    Selbst wenn ein Auftrag wirklich geplant wurde, ist es möglicherweise nicht die richtige Lösung, einen Compiler-Satz zu akzeptieren und ein Paar Klammern hinzuzufügen.


    In Bezug auf reinen Code müssen wir die Zuordnung und die Bedingung trennen. Es ist viel bequemer, eine Zeile für jede Aufgabe zu haben, dh das Prinzip der Einzelverantwortung zeilenweise anzuwenden:


    Bild

    Korrigieren Sie Compiler-Warnungen nicht automatisch, sondern nehmen Sie Korrekturen absichtlich vor.
    Teilen Sie dem Compiler mit, welche Arten von Warnungen für Sie wichtig sind.


    Es gibt verschiedene Möglichkeiten, mit dem Compiler zu arbeiten und keine Warnungen zu erhalten. Natürlich ist das Schreiben von Code, den auch der arme Compiler versteht, die beste Lösung. Es besteht jedoch auch die Möglichkeit, dem Compiler mitzuteilen, welche Warnungen für Sie von Interesse sind und welche nicht.


    Compiler-Flags


    Jeder uns bekannte Compiler bietet die Möglichkeit, die anzuzeigenden Warnungen auszuwählen. Sie können verschiedene Warnungsgruppen deaktivieren und manchmal einzelne Warnungen einer anderen Warnungsstufe zuweisen. In der Regel werden diese Funktionen als Befehlszeilenoptionen in den IDE-Einstellungen bereitgestellt. Dies bedeutet, dass Sie eine einzige Stelle - vorzugsweise Ihr Build-Skript - haben können, an der Sie diese Einstellungen anwenden können.


    Welche Warnflaggen verwenden? Dies hängt zum Teil vom Compiler ab, da verschiedene Compiler unterschiedliche Warnungen ausgeben und einige von ihnen möglicherweise nicht nur falsch, sondern verrückt sind.


    Einige Warnungen sind möglicherweise zu umständlich für Ihren Geschmack oder Ihre Art, Code zu schreiben, obwohl wir immer noch keine Warnungen gesehen haben, die keine Grundlage haben. (Generell ist es unserer Meinung nach besser, alle Warnungen durchzusehen, um das Wichtige nicht zu verpassen).


    Die Standard-Flags für die meisten Warnungen sind Wall, Wpedantic, Wextra (viele Compiler-Flags für Warnungen beginnen mit W).
    Wenn Sie gerade erst anfangen, eine Richtlinie ohne Warnungen auf Ihr Projekt anzuwenden, erhalten Sie höchstwahrscheinlich Hunderte oder sogar Tausende von Warnungen, wenn alle enthalten sind. Beginnen Sie mit einer niedrigeren Warnstufe. Korrigieren Sie die schwerwiegendsten Warnungen und erhöhen Sie nach und nach die Anzahl der Warnungen.


    Wenn Sie für Momente der Faulheit anfällig sind oder Kollegen gegen die Richtlinie „Keine Warnung“ sind, ist es gar nicht so einfach, sie zu deaktivieren. In  jemand möchten Sie den Code überprüfen , die eine Warnung enthält. Am Ende stellt sich heraus, dass dies kein Fehler ist, der Code kompiliert und wahrscheinlich wie vorgesehen funktionieren wird. Auf diese Weise werden eine Reihe von Warnungen nacheinander behoben.


    Um eine solche Zeitverschwendung zu vermeiden, können Sie die Richtlinie "Keine Warnungen" verstärken, indem Sie Warnungen auf Fehler umstellen. Daher können Fehler nur schwer ignoriert werden, andernfalls schlägt der Build einfach fehl. Dies kann sowohl mit einzelnen Warnungen als auch mit allen Warnungen gleichzeitig erfolgen. Setzen Sie das entsprechende -Fehler-Flag für Clang und GCC und / WX für MSVC.


    Pragma-Richtlinien


    Compiler verwenden häufig spezielle # Pragma-Anweisungen, um bestimmte Codewarnungen zu aktivieren oder zu deaktivieren. Diese Richtlinien sollten als vorübergehende Lösung betrachtet werden, da sie ihre Nachteile haben:


    • Das Deaktivieren von Warnungen mit #pragma übertönt den Compiler für die verbleibende Einheit. Wenn Sie diese Warnung nur einmal deaktivieren möchten, müssen Sie sie direkt nach der Codezeile mit der Frage aktivieren. Wenn Sie #pragma für die Header-Datei aktivieren und auf Warnungen verzichten, wird der Compiler für jede Quelle mit Header sowie für jeden Header nach #pragma wieder stummgeschaltet
    • Die # Pragma-Warnhinweise sind nicht portierbar. Die Bezeichner für jede einzelne Warnung variieren für verschiedene Compiler, ebenso wie das # Pragma-Format. Manchmal geben Compiler Warnungen über unbekanntes # Pragma aus - und Sie werden definitiv keine # Pragma-Warnung in den GCC schreiben wollen, dass diese MSVC-Warnungen ignoriert werden sollen. Das Einschließen in #ifdefs ist eindeutig nicht die beste Lösung.

    Es gibt Zeiten, in denen die Verwendung von #pragma nicht für Sie geeignet ist.


    Ein Beispiel sind die Header von Bibliotheken von Drittanbietern, die Sie nicht ändern können, und der Compiler beschwert sich darüber. Ein weiteres Beispiel ist eine einmal geschriebene einbettbare Sprache: Sie verwendete das Überladen von Operatoren auf ungewöhnliche Weise, wobei die integrierte Priorität von C ++ - Anweisungen ignoriert wurde .


    Der Compiler schlug hilfreich vor, zusätzliche Klammern hinzuzufügen. Dies könnte die richtige Entscheidung sein, wenn die Operatoren auf numerische Werte anwendbar wären. Damit der DSL-Code gelesen werden kann, muss in diesem Fall die Warnung stummgeschaltet werden, ohne den Code zu berühren. Das Deaktivieren der Warnung mit #pragma in Kombination mit einem erläuternden Kommentar hilft hier.


    Anstelle einer Schlussfolgerung


    Sie können den Compiler konfigurieren, indem Sie ihm mitteilen, welche Warnungen für Sie von Interesse sind und welche nicht. Verwenden Sie Befehlszeilenargumente oder, falls erforderlich, die # Pragmas-Direktiven. Versuche so streng wie möglich zu sein, füge nicht zu viele Ausnahmen hinzu. Dies bedeutet einen sorgfältigen Umgang mit # Pragmas und Abweichungen von Ihren Standardbefehlszeilenargumenten.


    PS Manchmal ist keine der oben genannten Methoden eine realistische Lösung. Verwenden Sie dann einfach den Befehl shut up für den Compiler.


    Jetzt auch beliebt: