Re: [boost] Patch bonanza for VS2013 Preview support

...

Agreed, VS2013 Preview's new C++11 features are looking solid.

Yay!

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?

...

Apart from http://connect.microsoft.com/VisualStudio/feedback/details/794707/sfin ae-fai lure-during-variadic-template-overload-resolution which is a showstopper for us that is.

That's actually a library issue, not a compiler issue. You're expecting C++14's SFINAE-friendly result_of, but you're getting C++11's SFINAE-hostile result_of.

(That's in addition to the fact that our result_of/<functional> implementation has numerous bugs with respect to C++11.)

Unfortunately, I won't be able to fix this in 2013 RTM. result_of needs to be thoroughly overhauled, but I'm not allowed to make such a major change at

I'm unclear why this is a C++14 issue. Nov 2012 CTP didn't have this problem. Libstdc++ nor libcxx have this problem. No other compiler has this problem. I also think you haven't looked at the bug closely enough - I'm *not* calling result_of<> in the way you think. Rather, I provide two overloads of call(), one non-variadic and one variadic: //! Invoke the specified callable when the supplied operation completes template<class R> inline std::pair, std::vector> call(const std::vector &ops, const std::vector> &callables); //! Invoke the specified callable when the supplied operation completes template inline std::pair::type>, async_io_op> call(const async_io_op &req, C callback, Args... args); I then call call() like this: Foo foo; std::vector ops; std::vector < std::function < int() >> callables; foo.call(ops, callables); It seems to me - by C++98 rules of not instantiating unneeded templates, never mind anything newer - that the closest matching overload is without doubt the first call() overload as the types match up exactly with type R=int. The second variadic call() should never have its result_of<> evaluated as the function's return type is unimportant here for overload resolution. I agree entirely that if the first call() was not there, then the compiler might think about trying to compile the second call() at which point it would fail, because the first parameter's type (const async_io_op &) does not match std::vector nor is there a conversion. Even then I don't think result_of<> should be compiled. this

point. I should be able to do this for the next major version, though.

You're the expert here, but the above looks strongly like an overload resolution calculation bug in the compiler's front end. Not a library bug. If so, that's a serious regression.

As an aside, why is Boost using std::result_of anyways? You've got Eric Niebler and his SFINAE-friendly boost::result_of, you know. :->

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. Why? Generally speaking Boost's C++11 facilities mirrors will cooperate with the native C++ standard library facilities, but the reverse is not true. For interoperabilities sake that's why we have to target the standard C++ library before all else when possible. Indeed, if when_all() and the other improvements in N3634 (which we partially implement in AFIO by the way) make it into the standard, and something like N3360 (Networking library) enters the standard, AFIO is very specifically designed to be 100% Boost independent such that it too can be proposed for standardization as a small extension of N3360. Niall --- Opinions expressed here are my own and do not necessarily represent those of BlackBerry Inc.