Boost logo

Boost :

From: Ferdinand Prantl (ferdinand.prantl_at_[hidden])
Date: 2004-07-16 10:52:20


Hi Volodya,

> From: boost-bounces_at_[hidden]
> [mailto:boost-bounces_at_[hidden]] On Behalf Of Vladimir Prus

[snip]

> > Borland: __WIN32__ _WIN32
> > Digital Mars: _WIN32
> > GCC (MinG/W and Cygwin with -mno-cygwin): __MINGW32__ WIN32 _WIN32
> > __WIN32 __WIN32__
> > Metrowerks: _WIN32
> > Microsoft: _WIN32
>
> It seems that _WIN32 is defined by all of them....

Yep, _WIN32 is enough from the hard-wired switches to be sure about the
Win32
platform, at least for what have done all the time.

I forgot Watcom, which defines _WIN32 __WINDOWS_386__ :-)
but they have still a long way to compile boost.org...

> > The macro WIN32 is meant to be a user-definable option how
> to enforce
> > a WIN32 code if a compiler does not define _WIN32.
>
> Ok. When is it needed, BTW?

Well, you have caught me. Actually, I did not need to use it yet. I have it
in
my configuration just to be flexible waiting for such code or compiler...

AFAIK, MSVS from some interesting reasons keeps to generate new wizards-made
projects and makefiles with the macro WIN32, dunno why. They may have some
old sources with both

#ifdef _WIN32
#endif

and

#ifdef WIN32
#endif

and it does not pay off to them to correct it, I do not know. I use -DWIN32
as well
in my makefiles and PLATFORM_WIN32 = _WIN32 || WIN32 in headers even if
_WIN32
alone should be always enough.

> > And if you like, it is possible to do something like this
> to be complete:
> >
> > BOOST_WIN32 : _WIN32 || WIN32
> > BOOST_WIN64 : _WIN64| WIN64
> > BOOST_WINDOWS : BOOST_WIN32 || BOOST_WIN64
>
> Yea, I think this makes sense. Though _WIN64 is not used
> anywhere in config yet.

It will start shortly, as soon as someone with a fresh new x86-64 from AMD
starts
to play with the boost::filesystem :-)

Today one should be careful with BOOST_WINDOWS and check the 64-bit
compatibility,
if the macro will mark general Windows platform.

Ferda

> - Volodya


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