Farid Zaripov wrote:
-----Original Message-----
From: Martin Sebor [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 16, 2006 8:20 PM
To: [email protected]
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.
Martin
