Paul, "Paul A. Bristow" <[EMAIL PROTECTED]> wrote
> You are probably right - but the tool tip display shows an __int64 which alerted > me to this. For most purposes, I suspect this warning /Wp64 is not what most > people want.(Or is it Boost policy that code should provide 64-bit portability? > Premature?) Intellisense does not work very well with template and preprocessor stuff. > > If one writes: > > std::size_t s = 42; > cout << s << endl; > > with MSVC7.0 default project settings for an empty console project on my 32-bit > system > > /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D "_MBCS" /GF /FD /EHsc /ML /GS /Gy > /Fo"Release/" /Fd"Release/vc70.pdb" /W3 /nologo /c /Wp64 /Zi /TP > > it is confusing to get a warning: > > test_size_t.cpp(19) : warning C4267: 'argument' : conversion from 'size_t' to > 'unsigned int', possible loss of data > > (I am unclear why there is a warning unless unsigned int is 32-bit and size_t is > 64-bit. How is there a problem if both are 32 or 64?) > Basically the /Wp64 option tries to find portability problems for types that are 32 bit on the Win32 platform and 64 bits on the Win64 platform. Usually the definition is selected based on the preprocessor macros for the platform #ifdef _WIN64 typedef __int64 xy; #else typedef int xy; #endif The compiler will NOT take the above into account when checking for W64 compatibility ( at that point the preprocessor has already run). Instead you should provide a hint to the compiler that a given type will be 8 bytes on the 64bit platform. You can use __w64 for this purpose. E.g. int i = (int)(void*)0; // warning typedef __w64 int ptr_int; ptr_int j = (ptr_int)(void*)0; // Ok /Wp64 will not detect cases where you have overloads (and that's true for your example). That is: first overloads are selected, then the compiler thinks "what if pointers (and types qualified with __w64) were be 64 bit?" ::size_t is implicitly __w64 and that cause the bogus warning. It is IMHO a better idea to do complete Win64 builds. It's pretty simple to build solutions/projects from the command line. Just open the Win64 console build environment and use devenv with the /useenv switch. The SDK compiler front end is based on an early version of 7.1 which could cause some headache. > If one changes to warning level 4/W4 and no test for 64 portability /Wp64 > > /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D "_MBCS" /GF /FD /EHsc /ML /GS /Gy > /Fo"Release/" /Fd"Release/vc70.pdb" /W4 /nologo /c /Zi /TP > > No warnings. > > And ideally request 'strict' - no extensions and for scope: > > /D "WIN32" /D "NDEBUG" /D "_CONSOLE" /D "_MBCS" /GF /FD /EHsc /ML /Za > /Zc:forScope > /Fo"Release/" /Fd"Release/vc70.pdb" /W4 /nologo /c /Zi /TP > > Still no warnings. BTW: You should be able to use /Zc:wchar_t without problems with the C++ standard library, too. It makes wchar_t a built-in type ( and not a typedef for unsigned short ). > > PS Despite RTFM, I cannot see how to change the IDE _default_ solution/project > settings. Suggestions? > You could update the script files in VC7\VCWizards\(Project)\scripts\*.js Just add a ClTool.WarningLevel = 4 somewhere. I haven't tried but I think it should work. -hg _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost