John Maddock wrote:
Guys,
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 this problem until it bites them <g>. I am glad at least you realize its ramifications.