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

[Howard Hinnant]

On Nov 27, 2011, at 1:39 PM, Ruben Van Boxem wrote:

> 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?

I haven't yet reviewed the patch in your previous email, but I've put it on my to-do list.

As for moving constructors:  I would be against this if it turns non-inlined code into inlined code.  What is inlined and what is not has been relatively carefully chosen.

Howard