----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/41460/#review112480 -----------------------------------------------------------
3rdparty/libprocess/include/process/future.hpp (lines 220 - 223) <https://reviews.apache.org/r/41460/#comment172929> Now that we're not taking `f` as a universal reference for each of these methods it seems that we might make two copies (one when we invoke the function and the second when we capture `f` in the lambda)? Can we add a TODO to move capture `f` once we have C++14? Or alternatively should we use `std::bind` here so we can explicitly move it and then convert back to lambda syntax once we have C++14? 3rdparty/libprocess/include/process/future.hpp (line 226) <https://reviews.apache.org/r/41460/#comment172931> I'd love to see a comment here that says: This is the less prefered `onReady`, we prefer the `onReady` method which has `f` taking a `const T&` parameter. Unfortunately, to complicate matters, if `F` is a `std::bind` expression we need to SFINAE out this version of `onReady` and force the use of the preferred `onReady` (which thankfully works because `std::bind` will just ignore the `const T&` argument). This is necessary because Visual Studio 2015 doesn't support using the `std::bind` call operator with `std::result_of` as it's technically not a requirement by the C++ standard. And then let's add a comment over the other `LessPrefer` variants that points up to the `onReady(F f, LessPrefer)` that includes this comment. 3rdparty/libprocess/include/process/future.hpp (lines 228 - 230) <https://reviews.apache.org/r/41460/#comment172930> Why do we need to capture/alias the type `F` as `G` again and then use it in `std::result_of<G()>::type`? Why can't we just use `F` there again? 3rdparty/libprocess/include/process/future.hpp (line 291) <https://reviews.apache.org/r/41460/#comment172933> This is another spot that looks like we could have a double copy? 3rdparty/libprocess/include/process/future.hpp (line 297) <https://reviews.apache.org/r/41460/#comment172932> Do you know which compilers will elide this `std::move`? 3rdparty/libprocess/include/process/future.hpp (line 309) <https://reviews.apache.org/r/41460/#comment172934> Double copy? - Benjamin Hindman On Dec. 28, 2015, 3:42 p.m., Michael Park wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/41460/ > ----------------------------------------------------------- > > (Updated Dec. 28, 2015, 3:42 p.m.) > > > Review request for mesos, Alex Clemmer and Joris Van Remoortere. > > > Bugs: MESOS-4228 > https://issues.apache.org/jira/browse/MESOS-4228 > > > Repository: mesos > > > Description > ------- > > The Standard (C++11 through 17) does not require `std::bind`'s function call > operator to SFINAE, and VS 2015's doesn't. `std::is_bind_expression` can be > used to manually reroute bind expressions to the 1-arg overload, where > (conveniently) the argument will be ignored if necessary. > > Follow-up from [r40114](https://reviews.apache.org/r/40114/). > > > Diffs > ----- > > 3rdparty/libprocess/include/process/future.hpp > c9146e3a3ccf09dd37c5a8ac7000fbe84f3c710c > > Diff: https://reviews.apache.org/r/41460/diff/ > > > Testing > ------- > > `make check` on OS X, compiled on Windows. > > > Thanks, > > Michael Park > >
