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

Reply via email to