[boost] Re: Re: Better Intel-Win32 support

From: Edward Diener (eddielee_at_[hidden])
Date: 2003-06-04 10:24:27

John Maddock wrote:
>> That will certainly work, but you shouldn't have to do that since the
>> compiler itself defines _WCHAR_T_DEFINED. Since I made the fix
>> earlier
> this
>> afternoon I am able to compile some non-boost code correctly which
>> had previously be failing.
>
> Just let me jump in here: you absolutely can not use _WCHAR_T_DEFINED
> to detect native wchar_t support: the windows headers will define
> this when wchar_t has been defined as a typedef (and wchar_t is not a
> native type). There appears to be no way to actually tell whether
> wchar_t is a native type or not with Intel.
>
> One other point: turning wchar_t support on may cause linker errors
> because you have now changed the name mangling of functions that take
> wchar_t as an argument - I don't know for sure but I would expect
> this to affect the std lib.

I don't know about Intel-Win32 but I brought much of this up regarding MSVC
7.0+ and most everybody yawned. I am glad that some people have woken up to
the fact that there is a problem using wide characters with compilers which
support both the native C++ wide character and a previous typedef for
wchar_t. A disappointing aspect of this in regards to MSVC 7.0+ is that
there is no preprocessor macro ( as of 7.0, I haven't checked 7.1 yet )
which MSVC defines for distinguishing native C++ wide character from the
previous typedef for wchar_t. And as you have said, serious linker errors
will occur for Boost libraries with wide character usage if they are built
for one or the other version of wide character and the end-user sets the
opposite version of wide character in their Makes or projects.

Although this is not a C++ problem or a Boost code problem directly, but
rather an implementation problem affecting a wide base of programmers, I
think Boost needs a clear strategy for dealing with it for any Boost library
built with wide character support and that all such libraries conform to
that strategy. Of course it's a PITA, and of course MS brought it on
themselves by supporting a non-C++ version of wchar_t for many years ( and I
am guessing that Intel, in order to be a plug-in for VC++ followed suit ),
but it still needs to be dealt with in some logical manner.