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.
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
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). this
problem until it bites them <g>.
'Cos, it's a complete pain in the you know where... <g> John.