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 Wed, 16 Aug 2006 17:20:25 GMT
Farid Zaripov wrote:
> -----Original Message-----
> From: Farid Zaripov [] 
> Sent: Friday, August 11, 2006 2:31 PM
> To:
> Subject: RE: [PATCH] Windows infrastructure for generating VisualStudio
> projects and solution(s)
>>-----Original Message-----
>>From: Martin Sebor []
>>Sent: Thursday, August 10, 2006 4:03 AM
>>Subject: Re: [PATCH] Windows infrastructure for generating 
>>VisualStudio projects and solution(s)
>   I'll make the all proposed changes.

Sounds good.

>   Also I propose to turn on the option /Zc:forScope. This option is
> present in MSVC 7.0
> and later versions (ICC 9.0 and later has this options too) and is off
> by default.

In principle I see no problem turning this option on for tests,
examples, or even the library sources (i.e., .cpp files) as long
as we continue to make it possible to compile our library headers
without this option on the command line. Since we also need to
verify that this is possible we should not enable it across the
board. I suppose we could exercise this in a single test so that
all the other tests don't need to worry about it. Feel free to
put together such a test :)

>   And another option: /Zc:wchar_t:

This one is tricky because it changes the ABI of the library. We
can't just turn it on by default since users may not want to or be
able to use it in their programs if they also link with third party
C++ libraries that do not make use of this option. What we might
want to consider doing, though, is building the stdcxx library in
a way that would make it possible to use its headers both with and
without the option without recompiling the library. 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).

FWIW, it was a really, REALLY bad decision on Microsoft's part not
to enable wchar_t as a native type by default. It makes the default
invocation of the compiler badly broken from a conformance standpoint
and it makes writing portable programs that much more difficult (by
making it impossible to overload on wchar_t and unsigned short).

>   When I link the my project (compiled with this option turned on) with
> stdcxx library I got the linker errors
> "unresolved external symbol "... <wchar_t>..."".

Right. That's because the mangling of wchar_t changes depending
on whether it's a typedef for unsigned short (w/o the option) or
whether it's a distinct type.


View raw message