On 24 Jun 2015 at 22:07, Brian Wood wrote:
Quite honestly, I'd rather have my library never get into Boost than bastardize it so it works on MSVC. If it can be made to work on MSVC without bastardizing it, however, I'm all for it.
I think you have a good chance of getting it working on VS2017, though with some effort by you to do the port. Not bastardising it, but rather reformulating your code to work around lack of two phase lookup etc. I hope you're not using lambdas in template template parameters. Chandler tells me MSVC can't mangle some of those, and has to stop dead same as winclang has to.
I face similar issues and agree with your remarks here. It seems like it's easier to use MSVC and Windows than it used to be, but it's still not easy. I've recently reduced my Windows support and feel a burden lifted.
I have found VS2015 quite remarkably better than anything before. In developing my lightweight monad recently which involves plenty of hefty C++ 11 and 14 metaprogramming, I mainly used clang 3.6 on Linux, and then pushed changes to my Jenkins CI without any further local testing. Out of 100 builds, about four failed with GCC 5.1 due to GCC having incomplete/buggy constexpr support. Out of 100 builds, less than ten failed on VS2015 due to me using a construct it didn't like. Of course, I was deliberately avoiding Expression SFINAE etc, but the point is that VS2015 has enormously closed the gap with clang and GCC. Over 90% of the time in my case these last few weeks VS2015 will compile any C++ 11 or C++ 14 I wrote and tested only using clang on Linux. That's quite something compared to where we were only a year ago. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/