3. Fehler seit Update von GCC

Fehler seit Update von GCC

  • C
    Mod

    -Weffc++ gibt es schon ewig, selbst gcc 3.3.6 spuckt

    test.cpp: In constructor \_Type::\_Type()': test.cpp:9: warning:_Type::str' should be initialized in the member
    initialization list

    aus. Leider wird nicht auf den tatsächlich vorhandenen Fehler (Verwendung eines reservierten Bezeichners) trotz -pedantic und -ansi hingewiesen.

    0
  • ?

    Vielleicht bringt das vollkommen sinnlose typedef den Compiler aus dem Tritt?

    0
  • P

    manni66 schrieb:

    Vielleicht bringt das vollkommen sinnlose typedef den Compiler aus dem Tritt?

    Wäre ein schlechter Compiler, wenn es das täte. Das sinnlose typedef ist C-Style...

    0
  • ?

    pumuckl schrieb:

    manni66 schrieb:

    Vielleicht bringt das vollkommen sinnlose typedef den Compiler aus dem Tritt?

    Wäre ein schlechter Compiler, wenn es das täte. Das sinnlose typedef ist C-Style...

    Naja, du nimmst hoffentlich nicht an, dass der GNU-Compiler fehlerfrei ist. Gerade weil es alter C-Style aber eben mit std::string ist, hat es vielleicht niemand getestet.

    0
  • P

    manni66 schrieb:

    Naja, du nimmst hoffentlich nicht an, dass der GNU-Compiler fehlerfrei ist. Gerade weil es alter C-Style aber eben mit std::string ist, hat es vielleicht niemand getestet.

    Ich nehme nicht an, dass der Compiler fehlerfrei ist. Vielmehr gehe ich aber davon aus, dass so ein doch relativ häufig benutztes Konstrukt wie das typedef nicht mit der Generierung des Defaultkonstruktors interferiert, das wäre schon ziemlich tragisch. Und die Warnung kommt nunmal aus dem generierten Ctor und sieht das typedef überhaupt nicht.

    0
  • C

    Athar schrieb:

    Außerdem scheint Code::Blocks ein Problem mit "note: " zu haben und interpretiert das als Compilerfehler.

    OK, das ist das Problem. Ich verwende Code::Blocks und ich hab mich gefragt wieso die "note" als fehler gewertet wird. Ich hab mich nur gewundert, wieso bei meinen Projekten aufeinmal so viel rot (kompilierfehler) ist.

    Danke für die Antworten.

    Weiß jemand was die note genau zu bedeuten hat? Die Warnung ist ja klar, aber die note sagt mir gar nichts.

    0
  • V

    Caster schrieb:

    Athar schrieb:

    Außerdem scheint Code::Blocks ein Problem mit "note: " zu haben und interpretiert das als Compilerfehler.

    OK, das ist das Problem. Ich verwende Code::Blocks und ich hab mich gefragt wieso die "note" als fehler gewertet wird.

    Echt? Bei
    Compiler/Global Compiler Settings/Advanced Options/Compiler Note
    steht bei mir als Maske

    ([][{}() \t#%$~A-Za-z0-9_:+/\.-]+):([0-9]+):[ \t]([Nn]ote:[ \t].*)

    und als Typ "Info".
    Und die note:-Zeile aus diesem Thread analysiert er auch richtig und erkennt sie als Info.
    Und mein Code::Blocks unter Windows ist 14 Monate alt.

    0

  • Caster schrieb:

    Weiß jemand was die note genau zu bedeuten hat? Die Warnung ist ja klar, aber die note sagt mir gar nichts.

    Das is nur ne Info, wo die impliziert definierte Funktion (hier der Default-Ctor) zum ersten mal gebraucht wurde.
    Weil die implizit definierten Funktionen erst erstellt werden, wenn sie gebraucht werden.

    Angenommen der Default-Ctor kann nicht implizit definiert werden, und angenommen das soll auch so sein (Klasse ist halt nicht kopierbar). Dann reicht mir die Info "Default-Ctor kann nicht implizit definiert werden" nicht. Irgendwo im Programm versucht jmd. den Default-Ctor zu verwenden, und diese Stellen muss ich finden. Wenn ich die mit Hand suchen muss, wäre das lästig. Also der Hinweis vom Compiler, welches Stück Code den Versuch getriggert hat den Default-Ctor zu erstellen.

    0
  • C

    @hustbaer: Danke für die Erklärung.
    @volkard: Ja die Zeile steht bei mir auch drin und wenn ich die zeile zum testen eingebe wird die auch erkannt. Ich weiß nicht was da dann nicht passt.
    Vielleicht ist da in meinen configs was durcheinander geraten.

    0
  • A

    Wenn man die Nachricht alleine eingibt, dann passt es.
    Die vollständige Zeile passt aber nicht mehr, z.B.:
    main.cpp:11:10: note: synthesized method ‘_Type::_Type()’ first required here

    Das dürfte daran liegen, dass sie vorher von der "Preprocessor error"-Regexp als Fehler eingestuft wird:
    ([][{}() \t#%$~A-Za-z0-9_:+/\.-]+):([0-9]+):[0-9]+:[ \t](.*)

    Wenn man die Reihenfolge tauscht, geht es wieder.

    0
Anmelden zum Antworten