Re: [boost] Patch bonanza for VS2013 Preview support

[Niall Douglas]

You've done well, though I have to say that so far at least the Preview feels slightly rough around the edges. For example, when working with Boost with all its available C++11 turned on, I'm seeing repeated errors from the linker of this form: fatal error C1128: number of sections exceeded object file format limit : compile with /bigobj ... and recompiling Boost with /bigobj for every compiland does indeed do the trick. This didn't happen with Nov 2012 CTP though. Have any other Boosters seen the same problem? Is /bigobj going to have to be made default on for all Boost?

According to my understanding, this happens when you emit more than 64k functions. The compiler really should enable /bigobj by default (or at least automagically) but for historical reasons it doesn't.

I'm unclear why this is a C++14 issue. Nov 2012 CTP didn't have this problem.

I'd have to investigate to figure out exactly what happened, but we changed result_of between 2012 and 2013.

I also think you haven't looked at the bug closely enough - I'm *not* calling result_of<> in the way you think.

Hmm. VC rejects this code: C:\Temp>type purr.cpp template <typename T> struct NoCharsAllowed { static_assert(sizeof(T) > 1, "No chars allowed!"); }; template <typename A> void purr(int, const A&); template typename NoCharsAllowed<B>::type purr(void *, const B&, Types...); int main() { purr(1729, 'x'); } C:\Temp>cl /EHsc /nologo /W4 /c purr.cpp purr.cpp purr.cpp(2) : error C2338: No chars allowed! purr.cpp(10) : see reference to class template instantiation 'NoCharsAllowed<char>' being compiled However, GCC accepts it, contrary to my understanding of the Standard. My brain tells me that template argument deduction should run for the B overload even though it will ultimately be nonviable (because 1729 isn't convertible to void *). It also tells me that if it runs, the static_assert should really explode and not trigger SFINAE. Either GCC is wrong, or one of these parts of my mental model is wrong. I'll ask our compiler team.

AFIO by default uses the C++ standard library where possible, and Boost equivalents where not possible. The choice can be overridden at compile time of course.

Ok, that makes sense. Thanks, STL