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.