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

From: Edward Diener (eddielee_at_[hidden])
Date: 2003-10-31 19:02:10

John Maddock wrote:
>>> 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.

Then it is a documentation bug. I should know not to trust documentation,
even by MS, by now.

>
> 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).

I hear you. Perhaps regression tests can do some of this for you.

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

Agreed. And one caused by MS's unwilling to embrace wchar_t a long while
back. But there are many VC7+ programmers in the world so that any Boost
library implementation, like regex++, which uses wide characters needs to
deal with it.

My suggestion is to create a separate set of regex++ libraries for wide
character usage. Not only will this mean that those not using wide character
search and/or replace with regular expressions will have smaller libraries
distributed to them, but also you will have testing to do regarding VC++ and
wchar_t only on the wide character versions. Actually I have been meaning to
suggest for awhile that the regex++ libraries be broken into smaller library
pieces to aid in distribution. The POSIX functionality also can be put in a
separate library. Breaking regex++ into smaller libraries means a smaller
distribution of code if one never uses some of the less standard features
such as wide character and POSIX.