[config] Visual C++ 2013 RC support - variadic template failures
I updated boost/config Visual C++ support yesterday to add Visual C++ 2013 RC support. But Mat Berchtold reported that signals2 tests then started to fail. I confirmed that 2013 RC tests were failing for signals2 and several of its dependencies, and narrowed it down to variadic templates so reverted to defining BOOST_NO_CXX11_VARIADIC_TEMPLATES for 2013 RC. --Beman
On 20 Sep 2013 at 10:51, Beman Dawes wrote:
I updated boost/config Visual C++ support yesterday to add Visual C++ 2013 RC support. But Mat Berchtold reported that signals2 tests then started to fail. I confirmed that 2013 RC tests were failing for signals2 and several of its dependencies, and narrowed it down to variadic templates so reverted to defining BOOST_NO_CXX11_VARIADIC_TEMPLATES for 2013 RC.
I fear the cause may be the same brittle N3276 decltype VS2013 implementation I found breaking my variadic template overloads in AFIO. The main problem I found is that VS2013's decltype is too quick to generate compile errors when fed an attempt to invoke call on a non-callable. I tried working around the problem by trying to partially specialise a filter template type with all callable types in order to avoid doing a decltype on slightly incorrect input. I was successful in all but lambda types, because I couldn't figure out how to get VS2013 to select a partial specialisation for lambda types i.e. I didn't figure out how to replicate the trick on VS2013 of accessing the call operator in the unknown lambda type like you can do on GCC or clang. I ran out of time to experiment further, so I hacked out the opposite filter of disabling the variadic overload for known non-variadic overloads and diverting everything else to the variadic overload. I hope this is useful to anyone else facing the same problem. Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
[Niall Douglas]
I fear the cause may be the same brittle N3276 decltype VS2013 implementation I found breaking my variadic template overloads in AFIO. The main problem I found is that VS2013's decltype is too quick to generate compile errors when fed an attempt to invoke call on a non-callable.
That sounds like you're trying to use Expression SFINAE, which VC does not yet support in full generality, instead of N3276 decltype, which specifically revolves around the completeness of call expression types. STL
On 20 Sep 2013 at 17:22, Stephan T. Lavavej wrote:
[Niall Douglas]
I fear the cause may be the same brittle N3276 decltype VS2013 implementation I found breaking my variadic template overloads in AFIO. The main problem I found is that VS2013's decltype is too quick to generate compile errors when fed an attempt to invoke call on a non-callable.
That sounds like you're trying to use Expression SFINAE, which VC does not yet support in full generality, instead of N3276 decltype, which specifically revolves around the completeness of call expression types.
You're right of course, but it's hard for me to work around VS2013's limitations here without being able to specialise a template for lambda types. Would you know Stephan how to do this on VS2013? I appreciate if it were easy you'd have already fixed the std::result_of<> shipped in the STL, but maybe it's easier than I am thinking? Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
On Sat, Sep 21, 2013 at 2:16 AM, Niall Douglas
On 20 Sep 2013 at 17:22, Stephan T. Lavavej wrote:
[Niall Douglas]
I fear the cause may be the same brittle N3276 decltype VS2013 implementation I found breaking my variadic template overloads in AFIO. The main problem I found is that VS2013's decltype is too quick to generate compile errors when fed an attempt to invoke call on a non-callable.
That sounds like you're trying to use Expression SFINAE, which VC does not yet support in full generality, instead of N3276 decltype, which specifically revolves around the completeness of call expression types.
You're right of course, but it's hard for me to work around VS2013's limitations here without being able to specialise a template for lambda types.
Would you know Stephan how to do this on VS2013? I appreciate if it were easy you'd have already fixed the std::result_of<> shipped in the STL, but maybe it's easier than I am thinking?
If it would help the workaround, we can add an additional BOOST_NO_CXX11_WHATEVER macro. Just let me know. --Beman
[Niall Douglas]
You're right of course, but it's hard for me to work around VS2013's limitations here without being able to specialise a template for lambda types. Would you know Stephan how to do this on VS2013? I appreciate if it were easy you'd have already fixed the std::result_of<> shipped in the STL, but maybe it's easier than I am thinking?
I don't know how. My plan is to ask the compiler for targeted Expression SFINAE support when I get to implementing the SFINAE result_of rules. STL
On 21 Sep 2013 at 19:58, Stephan T. Lavavej wrote:
[Niall Douglas]
You're right of course, but it's hard for me to work around VS2013's limitations here without being able to specialise a template for lambda types. Would you know Stephan how to do this on VS2013? I appreciate if it were easy you'd have already fixed the std::result_of<> shipped in the STL, but maybe it's easier than I am thinking?
I don't know how. My plan is to ask the compiler for targeted Expression SFINAE support when I get to implementing the SFINAE result_of rules.
Thanks for the quick answer. I discoved an answer to half of my problem: using unary + on a non-capturing lambda type erases the lambda-ness and produces its equivalent callable function pointer type, something easily specialised for and therefore filterable out to inhibit that overload for consideration. All that remains now is to figure out a way of specialising for capturing lambda types. Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
participants (3)
-
Beman Dawes -
Niall Douglas -
Stephan T. Lavavej