stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <>
Subject Re: [PING] FW: [PATCH] Windows infrastructure for generating VisualStudio projects and solution(s)
Date Thu, 17 Aug 2006 17:26:31 GMT
Farid Zaripov wrote:
>>-----Original Message-----
>>From: Martin Sebor [] 
>>Sent: Wednesday, August 16, 2006 8:20 PM
>>Subject: Re: [PING] FW: [PATCH] Windows infrastructure for 
>>generating VisualStudio projects and solution(s)
> [...]
>>I think the native C++ Standard Library that 
>>comes with MSVC makes this possible (although I'm not sure if 
>>it does it in the same binary or if they actually ship two 
>>binaries compiled from the same sources, one with the option 
>>and one without).
>   Sure. The MSVC C++ Standard Libraries (libcpxx.lib, msvcprtx.lib)
> includes
> unsigned short and wchar_t overloads simultaneously. Although for COM
> supporting the Microsoft provided the distinct libraries: comsuppx.lib
> with
> unsigned short overloads and comsuppwx.lib with wchar_t overloads.
>   I tried to define wchar_t as typedef to __wchar_t instead of unsigned
> short
> since __wchar_t is defined always,

This might simplify our solution: instead of using wchar_t with
MSVC we could use __wchar_t (suitably wrapped in a macro such as
_RWSTD_WCHAR_T) and, in addition, define overloads of the same
APIs for unsigned short and have them delegate to the __wchar_t.

Unfortunately, while this wouldn't be too hard to do for ordinary
functions it wouldn't be quite so easy for template specializations
(such as wofstream). I suspect we would have to provide explicit
specializations (or instantiations) on both types in the library.

  but in this case appears another
> problem:
> without /Zc:wchar_t option the type of L"abc" is unsigned short[4] and
> is
> not compatible with __wchar_t[4] :( As for me, __wchar_t is useless
> type.
>>FWIW, it was a really, REALLY bad decision on Microsoft's 
>>part not to enable wchar_t as a native type by default.
>   I think they preffered compatibility with the old sources,
> implemented with MSVC6, to the standard conformance :)

Yeah, but they broke both source as well as binary compatibility
in so many other ways that this should not have been an issue.


View raw message