Mit welchem Warnlevel arbeitet ihr?
-
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
-
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.
-
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.