3. Mit welchem Warnlevel arbeitet ihr?

Mit welchem Warnlevel arbeitet ihr?

  • V

    HumeSikkins schrieb:

    3. Ok. Die Warnung kann man sicher ausschalten.

    widerrufe!

    for(int i=0;i<100;++i)
   if(i/100>=0.3)
      if(i/100<=0.7)
         cout<<i "liegt zwischen 0.3 und 0.7"<<endl;

    nach nem ähnlichen fehler suchten kommilitonen von mir nen ganzen tag lang.

    0
  • B

    Da braucht es aber schon ausgefeilter Datenflussanalysen, um die Konstantheit des Ausdrucks nachzuweisen. true ist einfach der Trivialfall einer Compilezeitkonstanten. Wenn ein Compiler ersteres beherrscht, sollte die Extraarbeit, die beiden Fälle auseinanderzuhalten, nicht mehr groß ins Gewicht fallen.

    0
  • ?

    @volkard: Ich denke nicht, dass der Compiler sowas wie in deinem Beispiel finden kann.

    @Hume: Ja ich weiss, dass die ersten beiden Fälle kein gültiges C++ sind. Aber ich finde das nunmal praktisch, direkt im Funktionsaufruf mit Kontruktoren die Parameter zu erstellen.
    Das ist eine Erweiterung von MS, die ich wirklich gerne nutze. Er warnt ja auch nicht davor, dass dieser Code nicht in Ordnung ist, sondern dass ich mich hiermit von Standard C++ verabschiede. :p

    0
  • C

    Hi,

    ich verwende nur Warnlevel 3. Ich würde ja gerne noch eins höher auf Maximum schalten, aber die ganzen Libs (teilweise sogar die Standardheader!) bringen mit auf Warnlevel 4 riesige Berge an Warnungen.

    ChrisM

    0
  • ?

    @Volkard: Das pushen und poppen (ja, es funktioniert so, wie du es beschrieben hast), scheint nicht zu helfen, wenn etwas geinlined wird, wie bei std::vector.
    Ich muss wegen vector nach wie vor eine Warnung global ausschalten. 🙄

    Aber wär ne nette Idee gewesen...

    0
  • W

    Also mein aktuelles Projekt (~80 Klassen) bringt unter VS.NET auf höchster Stufe (/W4 /Wp64) nicht eine Warnung.

    0
  • S

    -Wall -Wno-unknown-pragmas

    Unknown Pragmas, weil z.B. TinyXML die VC Pragmas im Code drin hat.

    0
  • ?

    MaSTaH schrieb:

    Also mein aktuelles Projekt (~80 Klassen) bringt unter VS.NET auf höchster Stufe (/W4 /Wp64) nicht eine Warnung.

    Die Warnung, die ich mit vector kriege, gibt es erst seit VS.Net 2003 (laut MSDN). 🤡

    0
  • V

    Optimizer schrieb:

    @Volkard: Das pushen und poppen (ja, es funktioniert so, wie du es beschrieben hast), scheint nicht zu helfen, wenn etwas geinlined wird, wie bei std::vector.
    Ich muss wegen vector nach wie vor eine Warnung global ausschalten. 🙄
    Aber wär ne nette Idee gewesen...

    ich glaub' es klappt für die ganze "condition ist always true" und "conversion may lose significant bits" und was sonst noch alles verwarnt wird, weil die coder zu faul waren. es warnt nicht den (afair) C4786 "bezeichner zu lang, um noch in die debug-infos zu passen". die muss man in der tat ausmachen.

    0
  • V

    Bashar schrieb:

    Da braucht es aber schon ausgefeilter Datenflussanalysen, um die Konstantheit des Ausdrucks nachzuweisen.

    ok, föllig falsches beispiel. aber trotzdem warnt der compiler mir hin und wieder mit "condition is always true" und das kann bei mir eigentlich nicht sein. und regelmäßig war's ein echter programmierfehler.

    0
  • W

    Optimizer schrieb:

    MaSTaH schrieb:

    Also mein aktuelles Projekt (~80 Klassen) bringt unter VS.NET auf höchster Stufe (/W4 /Wp64) nicht eine Warnung.

    Die Warnung, die ich mit vector kriege, gibt es erst seit VS.Net 2003 (laut MSDN). 🤡

    Ich weiß nicht so genau ob ich in dem Project überhaupt einen vector drin habe.

    0
  • ?

    Walli schrieb:

    Also mein aktuelles Projekt (~80 Klassen) bringt unter VS.NET auf höchster Stufe (/W4 /Wp64) nicht eine Warnung.

    man kriegt ja schon ne warnung bei Wp64 wenn man blos nen size_t ausgeben mit cout ausgeben will.

    std::size_t s;
std::cout << s << std::endl;

    🙄

    0
  • ?

    Ist ja auch richtig, weil es zu unterschiedlichem Verhalten führen kann, wenn man für 32 oder 64 Bit compiliert.

    0
  • ?

    ne das ist ne fehlwarnung.

    0
  • ?

    -pedantic -Wall -W -Wpointer-arith -Wdisabled-optimization -Wno-long-long -Wcast-qual -Wcast-align -Wredundant-decls -Wwrite-strings -Wconversion -Wmissing-noreturn -Woverloaded-virtual -Winvalid-pch -Winit-self -Wstrict-aliasing=2

    0
  • H

    Hab keinen Warnlevel. Man kann nur einzelne Warnungen ein- und ausschalten... 😞 ➡ Enthaltung.

    0
  • ?

    Ritter des size_t schrieb:

    ne das ist ne fehlwarnung.

    Wieso? size_t ist bei 64 Bit System für gewöhnlich (und vor allem bei einem Compiler, der das warnt) 64 Bit groß, während unsigned int bei diesem Compiler 32 Bit sein wird. Daher kann man auch erklären, dass bei diesem sagenumwobenen Microsoft-Compiler diese Warnung nur bei /Wp64 kommt. Die Umwandlung size_t -> unsigned int ist halt eben nicht verlustfrei.

    0
  • V

    Ich mach auch immer hoechstes Warnlevel. Denn ich meine mich erinnern zu koennen,
    als ich meine ersten paar Posts hier gemacht habe, wurde mir eingetrichtert, dass
    Warnungen nicht tolleriert, sondern beseitigt werden sollen. Und daran hab ich
    mich bis heute gehalten, auch wenn es mich schon die ein oder anderen Nerven
    gekostet hat ;).

    mfg
    v R

    0
  • G

    Optimizer schrieb:

    Ritter des size_t schrieb:

    ne das ist ne fehlwarnung.

    Wieso?

    Weil die STL Implementation zum MSC sowohl einen Stream Operator für 32 Bit ints, als auch für 64 Bit ints (Compilererweiterung) hat. Je nach Grösse von size_t kann somit der passende Operator aufgerufen werden. Deshalb ist die Warnung an dieser Stelle tatsächlich Unsinn.

    0
  • ?

    manche compilerwarnungen muss man einfach ignorieren sonst kommt man mit höchstem warnlevel nicht weit 🙄 🙄

    0
Anmelden zum Antworten