> On Jan. 3, 2016, 11:55 p.m., Benjamin Hindman wrote: > > 3rdparty/libprocess/include/process/future.hpp, line 291 > > <https://reviews.apache.org/r/41460/diff/1/?file=1166979#file1166979line291> > > > > This is another spot that looks like we could have a double copy?
See above: https://reviews.apache.org/r/41460/#comment172929 > On Jan. 3, 2016, 11:55 p.m., Benjamin Hindman wrote: > > 3rdparty/libprocess/include/process/future.hpp, line 300 > > <https://reviews.apache.org/r/41460/diff/1/?file=1166979#file1166979line300> > > > > Do you know which compilers will elide this `std::move`? See above: https://reviews.apache.org/r/41460/#comment172929 > On Jan. 3, 2016, 11:55 p.m., Benjamin Hindman wrote: > > 3rdparty/libprocess/include/process/future.hpp, lines 220-223 > > <https://reviews.apache.org/r/41460/diff/1/?file=1166979#file1166979line220> > > > > 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? > > Michael Park wrote: > Yeah, there are a few places where we potentially copy twice. I guess my > understanding was that we typically don't worry about performance unless it > becomes a clear problem. I think maybe what we do in this review is keep the > forwarding references for now and talk about the "pass-by-value & move" > pattern separately. Reverted to using forwarding references as before. We'll have a discussion around whether we want to adopt the "pass-by-value + move" pattern project-wide. > On Jan. 3, 2016, 11:55 p.m., Benjamin Hindman wrote: > > 3rdparty/libprocess/include/process/future.hpp, line 312 > > <https://reviews.apache.org/r/41460/diff/1/?file=1166979#file1166979line312> > > > > Double copy? See above: https://reviews.apache.org/r/41460/#comment172929 - Michael ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/41460/#review112480 ----------------------------------------------------------- On Jan. 5, 2016, 11:58 p.m., Michael Park wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/41460/ > ----------------------------------------------------------- > > (Updated Jan. 5, 2016, 11:58 p.m.) > > > Review request for mesos, Benjamin Hindman, 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 > bcb5668565298825056f1b48d48efe12d2e56e7c > > Diff: https://reviews.apache.org/r/41460/diff/ > > > Testing > ------- > > `make check` on OS X, compiled on Windows. > > > Thanks, > > Michael Park > >
