Gibt es eine GCC-option, um zu warnen, über das schreiben `das Feld` statt `this->Feld`?

Diesem folgenden code (mit einem bösartigen bug) kompiliert mit GCC ohne jede Vorwarnung. Aber, natürlich, es funktioniert nicht wie erwartet durch den Entwickler (mich).

#include <iostream>

struct A
{
    bool b;
    void set(bool b_) { this->b = b_; }
    bool get() const { return this-b; } //The bug is here: '-' instead of '->'
};

int main()
{
    A a;
    a.set(true);
    std::cout << a.get() << std::endl; //Print 1
    a.set(false);
    std::cout << a.get() << std::endl; //Print 1 too...
    return 0;
}

Die Warnung kann ich für den compiler (GCC-4.8) zu vermeiden, diese Art von typo?

Verlinkten Frage: gibt es eine Möglichkeit zu zwingen (oder warnen) der Zugriff auf member-Variablen/Funktionen mit this->?

  • Was ist, wenn einige seltsame Person will, abzüglich der this Zeiger durch einen booleschen Wert? Sollte er eine Verwarnung bekommen?
  • Vielleicht können Sie nicht. In einigen seltsamen Fällen wird Ihr code macht Sinn
  • Wenn Sie aktiviert haben die hypothetische Warnung option, die OP fragt, dann ja.
  • Dies ist richtig, C++ - Satz, also kein compiler erzeugt eine Warnung. Sollten Sie die Verwendung von statischen code-Analyse-tool statt.
  • meinen Sie nicht, Sie sollten? Sie könnten schalten Sie immer die Warnung, dass, wenn Sie wissen, dass ist wirklich das, was Sie tun wollen
  • Ich könnte mir vorstellen -Wconversion (implizite Konvertierung Warnungen), als Zeiger implizit in bool - aber das hat es nicht bekommen...
  • die meisten Compiler erzeugen Warnungen für "richtige" C++ - Sätze. Zumindest bei der Verwendung von expliziten Warnung Optionen.
  • Ich bin mir ziemlich sicher, dass es keine Warnung für diesen, jeden einzelnen Vorgang hier ist Recht sinnvoll in einem bestimmten Kontext.
  • Das ist die ganze Zeit in der realen Welt code, wie if(p && p->bla) würden Sie nicht warnen, dass für.
  • Ich denke, dies zeigt perfekt, warum unit-Tests Wert hat.
  • Nicht alltäglich für die Werte zurückgeben...
  • Wie über Warnung für das tun von Zeiger-Arithmetik auf this? Ich hätte nichts dagegen, eine solche option Warnung obwohl vielleicht nicht in -Wall.
  • Das würde Sinn machen in meinen Augen. Offenbar niemand sah, dass Sie als groß genug, ein Problem so weit, aber ich würde nicht dagegen, dass die Warnung entweder.
  • Vielleicht möchten Sie versuchen -Waddress (die aktiviert ist, indem Sie -Wall) und warnt davor, verdächtige Verwendungen von Speicher-Adressen. Allerdings bin ich zweifelhaft - Konvertierung von bool zu int ist gut definiert, Zeiger-Arithmetik (addition/Subtraktion, eine ganze Zahl zu/von einem pointer), und die Umwandlung von Zeiger auf bool sind auch alle Konvertierungen angegeben, die Häufig in der Praxis verwendet. Wenn so ein Konstrukt wie deins gab Warnungen, die false positives " wäre riesig, und die Warnung nur selten aktiviert werden.
  • verwenden Sie nicht this->. Das wird vermeiden das problem vollständig
  • double x,y; x == y; ist auch gültig, aber es ist eine offensichtliche Warnung für diesen Fall.
  • Nicht mit this ist manchmal nicht eine sehr gute option, wie das vererben von templates
  • Interessant, -Wpointer-arith nicht fangen.
  • Zwei weitere nicht-Echtzeit-Lösungen: wenn Sie ein tool wie Visual Assist, der Fehler ist viel schwieriger zu machen, weil es kann automatisch hinzufügen -> nach einem Zeiger. Sie können auch Ihre version control pre-commit-hooks zu stoppen Instanzen this- ohne > folgende.
  • "die meisten Compiler erzeugen Warnungen für "richtige" C++ - Sätze": ich würde so weit gehen zu sagen, dass alle Warnungen werden von "richtigen" C++ - Sätze. Wenn es nicht gültigen code, den Sie bekommen würde, sondern ein Fehler.
  • Zeiger-Arithmetik auf this sinnvoll sein können, aber umwandeln des Ergebnisses zu bool ist nicht. Clang ist -Wundefined-bool-conversion warnt impliziten Konvertierung von this zu bool, das ist immer wahr. Es könnte unter Umständen erweitert werden, um auch warnen, auf eine implizite Konvertierung von this-n zu bool, die ist auch immer wahr.
  • vorausgesetzt, das Objekt ist Teil eines Arrays und den Zugriff auf das vorhergehende, - dann gefeuert 🙂
  • Ugh, es sollte nur verboten, eine binäre Subtraktion ohne whitespace um es in den ersten Platz. @LưuVĩnhPhúc: ich weiß, dass das Häufig, aber ich halte es für eine schlechte Praxis. Es zwingt auch Sie, um den Namen der Basisklasse, wenn die Erben (wenn Sie abhängige Typen beteiligt sind), das ist ärgerlich und inkonsequent.
  • Sie haben Recht, die this-> sollten vermieden werden, wo möglich. Es gibt jedoch Fälle, wo this-> erforderlich ist (template-Vererbung), so ist es sollte angemerkt werden, dass die Orte, an denen this-> ist tatsächlich erforderlich, sind auch die Fälle, in denen eine fehlerhafte this-b ist ein Fehler (weil b ist nicht zugänglich ohne die this->). Also die Regel ist: benutzen Sie nicht this-> es sei denn, erforderlich.
  • Ich hoffe, dass die Menschen, die sich verschworen, um die Subtraktion ein boolescher Wert von einem Zeiger legal in C++ fühlen Sie sich zumindest ein wenig schuldig. Die Zeiger auf bool-Konvertierung ist nur zu verteidigen, sondern indem Sie die Subtraktion mit bools?

InformationsquelleAutor Caduchon | 2017-09-20
  1. 71

    Zu diesem Problem ist erkannt cppcheck:

    $ cppcheck --enable=all das-minus-bool.cxx 
Die überprüfung dieser-minus-bool.cxx... 
[das-minus-bool.cxx:7]: (warning) Verdächtige Zeiger-Subtraktion. Haben Sie die Absicht, zu schreiben, " - >'? 
(Informationen) Cppcheck nicht finden können, alle include-Dateien (benutzen Sie --check-config für details)

    War dies ohne include-Pfad gegeben. Wenn ich -I /usr/include/c++/4.8/, das Problem ist immer noch erkannt:

    Überprüfung dieser-minus-bool.cxx... 
[das-minus-bool.cxx]: (Informationen) Zu viele #ifdef-Konfigurationen - cppcheck prüft nur 12 der 45-Konfigurationen. Verwenden Sie --force um zu überprüfen, alle Konfigurationen. 
[das-minus-bool.cxx:7]: (warning) Verdächtige Zeiger-Subtraktion. Haben Sie die Absicht, zu schreiben, " - >'? 
[/usr/include/c++/4.8/bits/ostream.tcc:335]: (Stil) Struct '__ptr_guard " hat einen Konstruktor mit 1 argument, das nicht explizit ist. 
[/usr/include/c++/4.8/bits/locale_classes.tcc:248]: (Fehler) Freigeben ein Zeiger freigegeben: __c

    dann cppcheck langsam arbeitet sich durch die oben genannten #ifdef Konfigurationen.

    (Wie sehen a side note, die Fehler in local_classes.tcc ist ein false positive, aber dies ist sehr schwer zu sagen, für ein automatisiertes tool, als würde es brauchen, um bewusst sein, dass die catch block auf dieser Website darf nicht eingegeben werden, wenn der makro __EXCEPTIONS ist nicht gesetzt.)

    Disclaimer: ich habe keine anderen Erfahrungen mit cppcheck.

    • Ich lieber falsch positiv als heimtückische Fehler. 🙂
    • Natürlich... das tool scheint nicht zu erzeugen ist für viele in jedem Fall, und es erlaubt auch das schreiben von Unterdrückungen (dies noch nicht ausprobiert).
    • Das stimmt bis zu dem Punkt, wo man so viele false positives, dass können Sie nicht mehr sehen, die wichtige Warnungen.
    • das ist auch wahr. Ich habe das problem mit dem Intel-compiler. Ich kann es nicht deaktivieren Warnung auf boost. Ich bekomme mehr als 100.000 Warnung in den boost-Bibliotheken. Unmöglich zu sehen, meine.
    • Ich bin ein Cppcheck-Entwickler. Ich würde wirklich gerne, es wäre ein defacto-tool verwendet werden, um C/C++ - Entwickler. Und dann diese Antwort wäre gut genug für die op. Ich Frage mich, ob jemand versucht hat, Cppcheck und beschlossen, es war nicht gut für einige Grund? Ich würde mich freuen zu erfahren warum. Wir versuchen wirklich, zu vermeiden, Lärm in Cppcheck... ich zitiere @ArneVogel "das tool scheint nicht zu erzeugen ist für viele in jedem Fall". Wir haben Unterdrückungen, aber wenn Sie sehen, falsche Warnungen es wird empfohlen, dass Sie es melden, damit wir ihn beheben können.
    InformationsquelleAutor Arne Vogel
  2. 32

    Nein, this - b ist die Durchführung Zeiger-Arithmetik auf den Zeiger this trotz b ein bool Typ (b implizit in int).

    (Interessanterweise, können Sie immer set this + b auf einen Zeiger, wo b ist ein bool geben, da können Sie einen Zeiger auf eine Vergangenheit das Ende einer skalaren! So auch Ihre Lieblings - Undefiniertes Verhalten spotter erlauben würde, dass man.)

    Überprüfung von Array-Grenzen hat immer schon die Aufgabe ein C++ - Programmierer.

    Beachten Sie auch, dass in Ihren Fällen die Verwendung von this ist überflüssig: so einzuschränken das übermäßige verwenden, ist ein Weg, das problem Weg.

    • Eigentlich haben wir uns entschieden, von einer langen Zeit auf, systematisch this-> für die Verständlichkeit der Gründe beim Lesen den code. Vielleicht eine schlechte Idee. Aber mit der änderung, dass ist wirklich teuer jetzt.
    • Diese Entscheidung war völlig yucky. Wo ziehst du die Grenze? Aufruf private member-Funktionen mit this?! Das Geld ausgeben und zu beheben. Wohlgemerkt, ich benutze m_ für member-Variablen, und s_ für Statik. Zurück in meine box 😉
    • Intel Zeiger prüfen-compiler sollte fangen - icpp Option Qcheck-Zeiger. Zumindest wenn, wie in der Frage, die Gegenstand dieser Punkte die uns nicht verrechnet werden als ein array. Wenn zugeteilt, als ein array, icpp kann nicht prüfen, da, wie bereits erwähnt in der Antwort, es ist legal. Aber IMHO Objekt-Methoden, sollten Sie nicht sorgen, wie-Objekt zugeordnet ist, also wenn ich noch bei Intel würde ich wollen zu fangen. Es war gesprochen, das hinzufügen von solchen Prüfungen zu gcc oder LLVM.
    • Tatsächlich, pointer checker wäre nicht der Fehler der code im Beispiel, denn es druckt nur die Zeiger. Es wäre nur zu fangen, wenn Sie versuchte, Sie zu dereferenzieren.
    • mit this-> bieten die Garantie bei der Kompilierung, dass es ein Mitglied. Mit m_ oder s_ nicht verhindern, dass gegen eine lokale/Globale variable (leider) nicht unter diesem Namen. Es war der Grund. Aber, natürlich, könnte es interessant sein, zu öffnen, diese Entscheidung. StackOverflow ist nicht die beste Plattform, um zu diskutieren, die Art von Frage, die (glaube ich). Was könnte gut sein ?
    • Ich vermute, dass eine ausreichend clever compiler könnte eine Warnung ausgeben, die sich auf die Tatsache, dass bool(this-n) ist immer wahr. Zum Beispiel, klammerten sich bereits emittiert eine Warnung für implizite bool(this).
    • chat könnte ein guter Ort, um zu gehen.
    • Ich sehe nicht, wie irgendein Teil dieser Antwort ist relevant für die Frage über die Warnungen. Natürlich ist es Zeiger-Arithmetik. Das bedeutet nicht, dass es keine Möglichkeit gibt zu erkennen, dass es fischig oder eine Warnung generieren.
    • Naja, mir gefällt es: aber das ist das, was die voting-Mechanismus ist für. Bitte downvote; es hilft dem Nutzer dieser Website beurteilen, die Nützlichkeit von Antworten.
    • Ich habe immer verwendet m_ für member, aber ich hätte nie gedacht, um zu verwenden, ein anderes für statische Variablen. Ist dies etwas, das Sie haben an anderer Stelle gesehen? Es scheint wie eine gute Idee.
    • aber es nicht immer wahr: wenn b wahr ist und this == (A *)(sizeof A) (das ist eine rechtliche wenn auch unwahrscheinlich Standort für ein Eine auf zu existieren, zumindest auf Plattformen, auf denen die Größe eines Zeigers ist die gleiche wie die Größe der size_t, was wahr ist in den meisten Fällen) wird false zurückgegeben.
    • Wenn der compiler targeting Linux, zum Beispiel, es könnte davon ausgehen, dass /proc/sys/vm/mmap_min_addr hat seinen default-Wert 65536, und somit keine gültige Adresse innerhalb des Programms kann in der niedrigen 64kiB. Oder zumindest warnen, auf dieser Basis, wenn nicht sogar das optimieren der Weg der Mathematik. (Spaß Tatsache: ein use-case für das ändern des kernel-Einstellung mit Emulatoren/Wrapper (WEIN für 16-bit-binaries von QEMU, von DOSBOX) mit virtuellen Adressraum als Gast physischen Adressen: wiki.debian.org/mmap_min_addr. Scheinbar modernen QEMU und DOSBOX umgehen Sie es jetzt.)
    • Siehe stackoverflow.com/questions/1228161/.... Ich glaubst ich habe mein m_ und s_ wenn ich ein wee-Zange bei Goldman Sachs. Ich habe auch gesehen my als Präfix für Mitglieder und our als Präfix für Statik. Persönlich, obwohl ich nicht gerne verlassen Sie sich auf syntax-Färbung zu bezeichnen member-Variablen: Es ist ziemlich schwer zu konfigurieren vi zu tun!
    • Nein, [conv.ptr] sagt, dass der einzige Weg, um ein null-Zeiger ist nullptr oder ein integer-literal null, und [KONV.bool] sagt, dass alle anderen Zeiger sind true. Der einzige Weg, um ihn in eine situation, in der this-n ist false ist durch Undefiniertes Verhalten.

    InformationsquelleAutor Bathsheba
  3. 13

    Möchte ich Ihnen ein weiteres Werkzeug (abgesehen von cppcheck vorgeschlagen von @arne-vogel), was eine bessere visuelle Hilfe statt der Warnung gefragt:

    Verwenden clang-format automatisch formatieren Sie den code. Das Ergebnis könnte wie folgt Aussehen (abhängig von den Einstellungen), damit der Fehler besser sichtbar durch die Räume, die Hinzugefügt, um operator-:

    struct A {
  bool b;
  void set(bool b_) { this->b = b_; }
  bool get() const { return this - b; }
};
    • Wenn Sie können auch fügen Sie einige code, der Färbung oder compiler-Ausgaben-färben-Werkzeug in Ihrer Antwort würden Sie erhöhen Ihren Wert.
    • Ich bin nicht sicher, ob ich verstehe Ihren Vorschlag, ich bin mir nicht bewusst einem beliebigen editor oder IDE verwendet für die Entwicklung von software, die nicht über syntax-highlighting eingebaut.
    • Das macht mich alt, weil ich kenne ein paar, die nicht die syntax-highlighting-mindestens. Nvm. Ich war nur sagen, dass, wenn Sie gehen, um Hilfe von code-Formatierung zu fangen, das Problem (das ist ein guter Weg, IMO), dann verwenden Sie die Formatierung von compiler-Ausgaben usw. sowie zu erwischen, ebenso wie andere potenzielle Fehler.
    • Gute Idee. Aber tatsächlich, ich hasse es, wenn die editor-Formate mein code. Für die vielen (dummen) Gründen, die ich entscheiden, zu formatieren, die von einer Regel oder einem anderen im moment, aus Gründen der Lesbarkeit, zur ästhetischen Grund, für Geschichte Gründen,... ich bevorzuge es, die Kontrolle zu behalten auf diesem. By the way, ich habe bereits ein editor tun, auto-Vervollständigung, vorkompilieren, Formatierung hervorheben... Es war ein einfacher code, geschrieben sehr schnell, es ist nur mein Fehler.
    InformationsquelleAutor Simon
  4. -1

    Nein, es gibt keine Möglichkeit, eine Warnung erhalten. Die impliziten Konvertierungen, obwohl perverse, dürfen von der Sprache.

    Aber in diesem bestimmten Fall können wir besser machen - durch einwickeln der bool in einer wrapper-class, die explizite Konvertierungen und keine arithmetischen Operationen definiert.

    Dies führt zu einem compiler-Fehler, wenn sich logisch missbraucht, das ist normalerweise vorzuziehen, eine Warnung, wenn die logische Korrektheit ist das Ziel.

    Es ist interessant zu beachten, dass c++17 deprecates bool::operator++ als diese Arithmetik wird als übel angesehen.

    Beispiel:

    struct Bool
{
    explicit Bool(bool b) : value_(b) {}
    explicit operator bool() const { return value_; }
private:
    bool value_;

    //define only the operators you actually want
    friend std::ostream& operator<<(std::ostream& os, const Bool& b) {
        return os << b;
    }
};

struct X
{
    bool foo() {
        //compilation failure - no arithemetic operators defined.
        //return bool(this-b);

        //explicit conversion is fine
        return bool(b);
    }

    Bool b { true }; //explicit initialisation fine
};
    • ja, habe ich, und bot eine perfekte Lösung, die über den OP-Bedarf.
    • Dann habe ich auch wieder ein std::vector<Bool> reduzieren von Speicher ? Es ist offensichtlich nicht die Lösung. Ich will nicht zu ändern, eine grundlegende Art in meinem code...
    • Sie müssen nicht, Sie können explizit cast auf bool. In jedem Fall, nicht mit std::vector<bool> - es ist akzeptiert als ein fehlerhaftes Konzept in der standard-Bibliothek.
    • vielleicht für meinen neuen code. Aber was ist mit der überprüfung meiner aktuellen 2.500.000 Zeilen code ? Außerdem verwende ich std::vector<bool>. Der main unit verwenden von Arbeitsspeicher der code ist eine Klasse, in der mehrere sehr große Vektoren von booleschen Werten. Es ist leicht viel Speicher gespart, indem Sie von 5Go zu 1Go für eine normale Nutzung.
    • Wenn dieser Ansatz nicht funktioniert für Ihre speziellen use-case -, das ist in Ordnung. Der OP will einen compile-time-Prüfung, die er schreibt richtige Logik. Diese Lösung funktioniert. Es macht keine weiteren Ansprüche.
    • Ich bin nicht sicher, wie Sie Sie ersetzen ein problem mit mehreren anderen Problemen (ersetzt die alte Gebräuche der bool mit Ihrer benutzerdefinierten Klasse oder inkonsistent Codebasis, so dass Sie sicher, dass alle neuen Entwickler auch wissen über diese und verwenden Sie es, etc., und auch mit boilerplate-code alle über dem Platz) eine gute Lösung. Gut, tut es, was der OP wollte, aber ich ernsthaft hoffe, dass niemand wirklich macht.
    • Ich habe angeboten, einen workaround für die Frage, die Sie stellte. Wenn deine eigentliche problem ist etwas anderes, Sie mit allen Mitteln-post, und ich werde sehen, ob ich eine nützliche Antwort. Sorry, ich konnte nicht helfen dieses mal.
    • Ich ausdrücklich bitten, eine Warnung für den compiler.
    • Es gibt mehrere implizite Konvertierungen, die Warnungen generieren, z.B. -Wundefined-bool-conversion im Klang.
    • Nun, nichts falsch mit Ihrem Vorschlag, aber... ist es nicht übertrieben? Warum stoppen, um Bool? Warum nicht wir auch definieren Int, Float, Double, VolatileUnsignedLongLong, ..?
    • "Nein, es gibt keine Möglichkeit, eine Warnung erhalten. Die impliziten Konvertierungen, obwohl perverse, dürfen von der Sprache." Das ist ein non-sequitur. Viele (?alle Warnhinweise sind für Dinge, die erlaubt sind, durch die Sprache, aber vielleicht ein Fehler. Zum Beispiel if (a = f()) produzieren eine Warnung für viele Compiler (wird zum schweigen gebracht durch if ((a = f())).
    • da bool nur arithmetische geben die wohl nicht sein sollte Arithmetik.
    • gut, die Verpackung einer built-in-Typ scheint völliger overkill. Und auch, während es löst, das bestimmten version das problem wäre nicht gelöst werden alle möglichen, z.B. wenn das Feld zugegriffen wird, ist ein Zeiger, und die Methode ist die Rückgabe ein boolescher Wert, ob es null ist oder nicht. Plus Sie behaupten, dass die Tatsache, dass die Konvertierung ist zulässig als Teil der Sprache bedeutet, dass Sie nicht haben, können Sie eine Warnung für ihn, das ist nicht wahr, z.B. g++ gibt eine Warnung für einschränkende Konvertierungen in einigen Fällen, in denen die Sprache, die spec erlaubt es Ihnen.
    • und Richard: re: std::vector<bool>: Eine dynamisch-size-bitmap ist eine nützliche Daten-Struktur, aber es ist bedauerlich, dass C++ wählte, es zu nennen std::vector<bool> statt std::bit_vector oder so etwas. Das etwas, was ich denke, fast jeder Zustimmen können. Siehe isocpp.org/blog/2012/11/on-vectorbool für einige ausgezeichnete Punkte, vor allem, dass die standard-Bibliothek sollte so ein Typ, mit optimierten Implementierungen für std::find, std::count, und so weiter, denn das ist eine gute Möglichkeit zur Bereitstellung von Plattform-spezifischen popcnt / bit-scan-Zeug.
    • Und BTW, die klappern mit libc++ hat optimierte Implementierungen von einigen std:: algorithmen über std::vector<bool>, so Rollen Sie Ihre eigenen bit-Vektor nur zu vermeiden vector<bool> weh tun wird, die Leistung auf einigen C++ - Implementierungen.

    InformationsquelleAutor Richard Hodges
Schreibe einen Kommentar