Re: [Boost-users] BJAM and VS2013RC

Subject: Re: [Boost-users] BJAM and VS2013RC
From: Craig Henderson (hello_at_[hidden])
Date: 2013-09-19 12:26:22

VS2013RC does have deleted and default functions.

Sent from my iPhone

On 19 Sep 2013, at 17:20, "Niall Douglas" <s_sourceforge_at_[hidden]> wrote:

> On 18 Sep 2013 at 19:05, Lars Viklund wrote:
> 
>> Among them, I think pretty much only the Boost.Build patch has been
>> applied to trunk, the rest are suffering either from quabbling about
>> whether to support non-release compilers or plain neglect.
> 
> I've been running VS2013 RC last few days with the following 
> additional features above and beyond VS2013 Preview turned on:
> 
> //#define BOOST_NO_CXX11_DECLTYPE_N3276
> //#define BOOST_NO_CXX11_DEFAULTED_FUNCTIONS
> //#define BOOST_NO_CXX11_DELETED_FUNCTIONS
> //#define BOOST_NO_CXX11_TEMPLATE_ALIASES
> 
> It does seem to work. Mostly.
> 
> I say "mostly" because decltype() isn't a 100% equivalent to GCC or 
> clang's decltype(), so while VS2013's decltype is much better than 
> before, it still falls down.
> 
> Yesterday I spent some hours trying to get decltype to grok lambda 
> types for example. I eventually gave up - VS2013 kept getting upset 
> about "lambda types aren't constructible" etc. GCC and clang (going 
> back to 4.6 and 3.1) on the other hand fly past this with ease.
> 
>> It's still utterly impossible to run the regression test suite as a mere
>> mortal, so I have no idea what kind of regressions there are in Boost
>> between 2012 and 2013RC.
>> 
>> I'd like to put more effort into getting support for this upstream, but
>> it's way too frustrating to go through the effort to make decent patches
>> and have the majority of them ignored.
>> 
>> I wouldn't expect any form of formal support in Boost for VS 2013 until
>> whatever version releases after the 2013 RTM in November, way too late
>> for any actionable bug reports to Microsoft.
> 
> I think the caution is warranted. VS2013 is quite a different beastie 
> to VS2012. A good few months of testing is definitely in order. I 
> don't know if Stephen is reading this, but if he is, does Microsoft 
> flip on these features in Boost themselves to see how their compiler 
> runs? I'd assume they do.
> 
> Regarding the breakage of std::result_of<> in VS2013 under variadic 
> templates, in AFIO I ended up with this stupid line:
> 
> #if _MSC_VER == 1800 // specifically VS2013 only
> use preprocessor generated overloads;
> #else
> use variadic template overloads;
> #endif
> 
> I could work around SFINAE failure during variadic template overload 
> resolution on every single compiler we support except for 
> specifically VS2013 only, on which I gave up after many hours of head 
> bashing because its decltype() seems to me to be a bit brittle as 
> compared to other compilers (perhaps this is the letter of the 
> standard, though I thought decltype() gets much more relaxed in 
> C++14). I had a crack with Eric's decltype() based SFINAE capable 
> boost::result_of instead of std::result_of, but there I got different 
> breakages of overload resolution.
> 
> Anyway I've slept on it last night and I now have a new idea for 
> working around the problem so I can switch on variadic template 
> overloads in AFIO on VS2013. It is annoying that it's this hard 
> though, what I'm doing is a common use case many others will 
> encounter when writing C++11.
> 
> Niall
> 
> -- 
> Currently unemployed and looking for work.
> Work Portfolio: http://careers.stackoverflow.com/nialldouglas/
> 
> 
> 
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users