Mit welchem Warnlevel arbeitet ihr?

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.

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.

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;

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

ne das ist ne fehlwarnung.

-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

HEZ

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

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.

virtuell Realisticer

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

groovemaster

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.

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

Jester

In meinem letzten Projekt auf der Arbeit mußte ich auch zwei Warnungen drin lassen: einmal unreachable Code und einmal condition always true...

beides kam direkt aus der vector-Implementierung des BCB.

groovemaster schrieb:

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.

Wenn der Compiler Umwandlung von size_t nach unsigned int anmahnt, dann wird er wohl auch eine Umwandlung von size_t nach int machen wollen.
Mag ja sein, dass __int64 oder long long so nen Operator hat, aber scheinbar wird size_t zur Ausgabe wohl in ein unsigned int gecastet. Von mir aus ist das nicht mal standardkonform, aber so weit bin ich noch nicht, dass ich glaube, dass er den cast A anmahnt, aber eigentlich den cast B durchführt.

Jester schrieb:

In meinem letzten Projekt auf der Arbeit mußte ich auch zwei Warnungen drin lassen: einmal unreachable Code und einmal condition always true...

beides kam direkt aus der vector-Implementierung des BCB.

Hättst du da nicht warning-Direktiven drum rum setzen können?

Optimizer du hast doch die 2005 beta. Kommt da auch die Warnung?

Falls du << size_t meinst, ja.