>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.
Hum... I just had a thought. Is it possible to detect if wchar_t is a typedef at compile time?
Yes, I think so. Won't boost::is_same< unsigned short, wchar_t >::value be true if wchar_t is a typedef, and false if a distinct type?
I'll do some experiments.
--Beman
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
