[cfe-dev] [PATCH] Libc++ Windows fixes

[Ruben Van Boxem]

2011/11/27 Ruben Van Boxem <vanboxem.ruben at gmail.com>:
> Hi,
>
> I've been cracking at it again, and came up with the attached patch to
> let libc++ play nice with MSVC (or is it the other way around?).
>
> I created a new __config macro: _LIBCPP_HAS_BROKEN_DECLTYPE, which is
> defined for MSVC, and disables any functionality dependent on the
> functionality broken in MSVC 10 (and probably 11). This is all the
> __is_constructible stuff, and unfortunately this leads to other places
> this macro pops up.
>
> The good news: I've gotten through <type_traits>, adding the _MSC_VER
> checks alongside the already existing Clang and GCC checks. Perhaps a
> better way to handle this would be two new config macros:
> _LIBCPP_HAS_NOTHROW_INTRINSICS and _LIBCPP_HAS_TRIVIAL_INTRINSICS (not
> *_TYPE_TRAITS, as that's confusing, the type_traits stuff will always
> be present). I can fix that if that sounds sensible. The
> __is_standard_layout and __is_trivial are really just MSVC's __is_pod,
> I don't know how conformant this will be untill I am able to run the
> tests.
>
> The bad news: I've run into another language incompatibility, namely
> MSVC not allowing template function default template-arguments. I've
> looked in C++03 and my C++11 FDIS, and there's indeed a difference,
> and it is allowed in C++11 as far as I can see. But of course MSVC
> doesn't allow it. I believe I can disable the error (which seems to be
> a warning emitted by default as an error:
> http://msdn.microsoft.com/en-us/library/190h9wbh(v=VS.100).aspx), but
> I'm not sure if it'll have the wanted behavior (the default argument
> will be ignored).

I've found a workaround, but it might be unpretty codestyle wise:
currently, shared_ptr's constructors are declared inside the class and
defined outside of the declaration. This is causing MSVC to choke. I
can solve the compiler's problem by moving the definition inside the
class declaration. There are a couple more classes with the same
problem, and these can probably be solved in the same manner.
Specifically, one shared_ptr constuctor, one __split_buffer member
function, 8 vector constructors will need moving (as far as I can see
until now). Probably a whole lot more template classes need similar
retouching. Is it OK to go ahead and do this?

Ruben

>
> Comments and commits are welcome!
>
> Ruben
>