Mit welchem Warnlevel arbeitet ihr?

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.

groovemaster

Optimizer schrieb:

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.

Ne, da hast du was falsch verstanden. Hier geht es weder um signed/unsigned Geschichten, noch um Casts. size_t ist ja kein eigener Typ, sondern lediglich ein typedef, sozusagen ein Alias. Deshalb ist es unlogisch, dass eine Warnung ausgegeben wird, wenn size_t entweder unsingned int oder unsigned long long ist, und für beides entsprechende Stream Operatoren angeboten werden. Denn da wird weder gecastet, noch entsteht Datenverlust. Soviel zur C++ Theorie.
Leider hat MS hier etwas eingeführt, dass ihnen nun auf die Füsse fällt. Und zwar das kleine Keyword __w64. Dieses soll dafür sorgen, dass entsprechende Warnungen bzgl. 32/64 Bit Portabilität ausgegeben werden. Nun ist es aber so, dass ostream lediglich einen << Operator für unsigned int hat, nicht aber für __w64 unsigned int. Ob beides gleichzeitig möglich ist, oder aufgrund identischer Funktionssignaturen vom Compiler abgelehnt wird, weiss ich nicht. Dennoch ist, wie ich bereits sagte, eine Warnung an dieser Stelle vollkommener Unsinn.

Du hast Recht. Nachdem ich herausgefunden habe, dass ein operator<< für unsigned __int64 existiert, muss die warnung wohl allein wegen dem _w64 kommen. Das ist natürlich Müll.

#ifdef  _WIN64
typedef unsigned __int64    size_t;
#else
typedef _W64 unsigned int   size_t;

Inexcusably lame.