Mit welchem Warnlevel arbeitet ihr?

[Gast]

Umfrage: Welches Warnlevel?

Auswahl	Stimmen	Prozent
allerallerhöchstes	22	44.9%
ein hohes	16	32.7%
mittleres	8	16.3%
niedriges - ich weiss was ich tue!	2	4.1%
aus - ich glaube, ich weiss, was ich tue :rolleyes:	1	2.0%

Ich arbeite mit dem höchsten und wenn mir etwas wirklich dumm vorkommt, stelle ich ganz bestimmte Warnungen aus.
Außerdem zählen bei mir Warnungen als Fehler. Ich weiss jetzt zwar nicht, welche Compiler welche Warnlevel anbieten, aber ich denke, dass man bei den meisten Compilern genug einstellen kann.

[volkard]

//für MSVC60

ich arbeite natürlich aus prinzip mit dem höchsten level. denn ich habe "effektiv c++ programmieren" gelesen und ein wenig davon verstanden. naja, so war's damals mit dem Borland 3.1.

ich arbeite mit dem MSVC60. natürlich kann ich das warnlevel 4 (dort das höchste) nicht anmachen, weil es da locker 100 warnungen flockt, wenn man <map> und <iostream> inkludiert.

ich arbeite mit dem MSVC60, aber habs geschafft. dieses geile #pragma include_alias rettete mich. die arschlöcher von MS dachten an ersetzungen zwischen kurzen und langen dateinamen. nee. zwischen ungewarnten buggy versionen und meinen kapselunegn issen gut.

hab gernaue syntax nicht hier, aber so ungefähr:
jede meiner *.cpp inkludiert zuerst die <vhlib/bugfix.h>. die ist unter linux normalerweise leer, aber unter win sagt sie

#pragma include_alias(<iostream>,<vhlib/bugfix/iostream>)
//und noch so sachen

und in der <vhlib/bugfix/iostream> steht simplerweise

#pragma warning(pusch,3)
#include <iostream>
#pragma warning(pop)

oder so.
wie es exakt ist, weiß ich gerde nicht genau, wers mag, schicke mir ne mali, ich geb dann exakten code zurück.

[Gast]

lol, das ist ja lustig :p . Ich arbeite mit VS.Net 2003 und höchster Warnstufe und habe (bis auf eine Ausnahme) keine Probleme mit besagten includes.
3 Warnungen hab ich abgestellt, nämlich

// nonstandard extension used #1:
funktionsName(KlassenName(argumente));      // Übergabe als Referenz

// nonstandard extension used #2:
funktionsName(&KlassenName(argumente));     // Übergabe als Zeiger

// conditional expression is constant:
while (true)

Für diese Warnungen hab ich auch wirklich kein Verständniss.

Die Ausnahme ist in vector, da meckert er noch irgendwas mit unreachable code, lol, ist doch nicht meine Schuld.

[HumeSikkins]

Optimizer schrieb:

3 Warnungen hab ich abgestellt, nämlich

// nonstandard extension used #1:
funktionsName(KlassenName(argumente));      // Übergabe als Referenz

// nonstandard extension used #2:
funktionsName(&KlassenName(argumente));     // Übergabe als Zeiger

// conditional expression is constant:
while (true)

Für diese Warnungen hab ich auch wirklich kein Verständniss.

1. Wie sieht der Parameter von funktionsName aus? Wenn's ne Referenz ist, dann ist die erste Zeile kein gültiges C++. An Referenzen dürfen nur lvalues gebunden werden. Wenn's ne Referenz auf const oder ein value-Parameter ist, dann ist die Warnung käse.

2. Die zweite Zeile ist kein gültiges C++. Der Adress-Operator darf nur auf lvalues angewendet werden. Dein annonymes Objekt ist aber kein lvalue.

3. Ok. Die Warnung kann man sicher ausschalten.

[rüdiger]

beim gcc nehm ich immer:
-Wall -W (-std=c++98 oder -std=c99)

hat mir bisher immer gute Dienste geleistet

[Bashar]

-W -Wall -ansi -pedantic

[dreaddy]

Immer höchstes wenn ich ein neues Projekt anfange.
Wenn irgendwas dann zu schwachsinnig wird(weil der Borland seinen eigenen automatisch generierten Code anmeckert) schalte ich mal einzelne Warnungen aus wenns sein muss.

[volkard]

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.

[Bashar]

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.

[Gast]

@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

[ChrisM]

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

[Gast]

@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...

[Walli]

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

[SnorreDev]

-Wall -Wno-unknown-pragmas

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

[Gast]

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).

[volkard]

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.

[volkard]

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.

[Walli]

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.

[Ritter des size_t]

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;

[Gast]

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