Boost logo

Boost :

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


Paul,

"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
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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk