Re: [boost] Patch bonanza for VS2013 Preview support

Subject: Re: [boost] Patch bonanza for VS2013 Preview support
From: Niall Douglas (ndouglas_at_[hidden])
Date: 2013-07-24 10:52:58

> > 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.

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<future<R>>,
std::vector<async_io_op>> call(const std::vector<async_io_op> &ops, const
std::vector<std::function<R()>> &callables);

//! Invoke the specified callable when the supplied operation completes
template<class C, class... Args> inline std::pair<future<typename
std::result_of<C(Args...)>::type>, async_io_op> call(const async_io_op &req,
C callback, Args... args);

I then call call() like this:

Foo foo;
std::vector<async_io_op> 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<async_io_op> nor is there a conversion. Even then I
don't think result_of<> should be compiled.

> (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
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.