Re: [Boost-users] Re: Build+Install+/Zc:wchar_t in Visual studio builds

From: John Maddock (john_at_[hidden])
Date: 2003-10-31 06:27:24

> > We could of course create a new build variant to handle this, but
> > with 8 regex lib/dll variants already I'm not keen to add another 8
> > (apart from anything else testing already takes too long).
>
> I think you have to do this John if you want to support both the C++
wchar_t
> and the MS wchar_t in Boost libraries. Although there are VC++ predefined
> macros, _WCHAR_T_DEFINED and _NATIVE_WCHAR_T_DEFINED, which are defined
when
> /Zc:wchar_t is used, they are also stupidly defined, according to the
> documentation, when typedef unsigned short wchar_t is used ( talk about
> idiotic MS decisions ). So Boost needs to use a macro which the
> end-programmer must define which tells whether or not /Zc:wchar_t is being
> used or not, and create another set of libraries accordingly.

Testing for _NATIVE_WCHAR_T_DEFINED works perfectly well -  it is set by the
compiler only and not the headers.

As for moving to 16 (!) build variants, remember that this issue only
effects boost.regex at present: so the variants aren't needed for other
libraries (which makes a generic build and install system hard).  Remember
also how long it takes to test this - I don't think I've done anything with
my spare time this week, except test the new Boost.Install system with
regex, and I'm still only half way though building and running all the test
variants (takes about 2 hours per compiler toolset provided nothing nasty
shows up).

> The other choice of picking one, either /Zc:wchar_t or not, and then
telling
> developers that they will have to rebuild the library and maybe change its
> name for their opposite use, will be disappointing to end-users.
>
> I brought all this up a long time ago vis-a-vis VC++ 7+, but Boost
> implementors of wide character code seem to want to go along and ignore
this
> problem until it bites them <g>.

'Cos, it's a complete pain in the you know where... <g>

John.