mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benjamin Hindman" <b...@berkeley.edu>
Subject Re: Review Request 41460: Used `std::is_bind_expression` to SFINAE correctly.
Date Sun, 03 Jan 2016 23:55:44 GMT

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


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message