Boost logo

Boost :

From: Holger Grund (h.grund_at_[hidden])
Date: 2003-03-27 07:25:39


"Paul A. Bristow" <boost_at_[hidden]> 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
> Premature?)

Intellisense does not work very well with template and preprocessor

> 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
that are 32 bit on the Win32 platform and 64 bits on the Win64
Usually the definition is selected based on the preprocessor macros
the platform

#ifdef _WIN64
    typedef __int64 xy;
    typedef int xy;

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
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
(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
build environment and use devenv with the /useenv switch. The SDK
front end is based on an early version of 7.1 which could cause some

> If one changes to warning level 4/W4 and no test for 64 portability
> /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
> /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
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_
> settings. Suggestions?
You could update the script files in
Just add a ClTool.WarningLevel = 4 somewhere.
I haven't tried but I think it should work.


Boost list run by bdawes at, gregod at, cpdaniel at, john at