Re: [Boost-users] BJAM and VS2013RC

Subject: Re: [Boost-users] BJAM and VS2013RC
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2013-09-19 12:20:29

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/