wchar_t config question (was: Re: Microsoft Visual C++ portability hints)

From: Daryle Walker (darylew_at_[hidden])
Date: 2001-02-03 16:55:12

on 2/2/01 5:16 PM, Ed Brey at brey_at_[hidden] wrote:

> From: "Jens Maurer" <Jens.Maurer_at_[hidden]>
>> Ed Brey wrote:
>>> For wchar_t, it would be worth adding that a workaround is to include
>>> <cstddef>, which defines wchar_t, and this workaround is implemented in
>>> boost/config.hpp.
>> 
>> Thanks.  I've added that.
>> 
>> I believe that <cstddef> actually provides a typedef to short or so,
>> so I've added a note warning about possible overloading ambiguities,
>> since wchar_t is not a distinct type as required by the standard.
> 
> Good point regarding the ambiguity.  wchar_t is indeed typedefed to
> unsigned short.  The typedef is made in an MS header even with STLport
> installed, so it's a safe bet that things are the same with and without
> STLport.

This typedef is MS VC++-specific, right?  The type (wchar_t) is supposed to
be a built-in in C++.  (I think "wchar_t" is a typedef in C, but I suppose
that a C++ implementer blocks out that typedef in C++ mode.)  Odd that
you're giving this advice, since you [Ed Brey] deemed it unnecessary in the
latest final version of "boost/config.hpp":

//==========================================================================
# ifdef BOOST_NO_STDC_NAMESPACE
#   include <cstddef>
    namespace std { using ::ptrdiff_t; using ::size_t; }
    // using ::wchar_t; removed since wchar_t is a C++ built-in type (Ed
Brey)
# endif
//==========================================================================

> Following is a suggestion for the workaround paragraph that incorporates
> the information about unsigned short (which could be useful to someone
> dealing with this issue) and rearranges some wording from your draft that
> seemed awkward to me as I read it:
> 
> Workaround: The header boost/config.hpp includes <cstddef>, which defines
> wchar_t as a typedef for unsigned short. Note that this means that the
> compiler does not see wchar_t and unsigned short as distinct types, as is
> required by the standard, and so ambiguities may emanate when overloading
> on wchar_t.

Isn't there a configuration macro for this already:
BOOST_NO_INTRINSIC_WCHAR_T?  Anyone that doesn't have distinctions between
"wchar_t" and another built-in type should use that macro as a block around
the "wchar_t" code.

I have a question about the placement of the macro.  Shouldn't the macro be
in the "Conformance Flag" section, and not the "Compiler Control or
Information" section?  It seems that the other macros in the latter section
describe library screw-ups or additions.  The lack of a distinct "wchar_t"
is a basic language screw-up, and should be in the first section with the
other core language (and major library) problems.

-- 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com