> On Feb. 5, 2017, 12:59 a.m., Alex Clemmer wrote:
> > 3rdparty/stout/include/stout/os/windows/dup.hpp, line 20
> > <https://reviews.apache.org/r/54595/diff/6/?file=1624397#file1624397line20>
> >
> >     Tiny nits: Should we `#include` `try.hpp` and `unreachable.hpp` also? 
> > Also, in this case, I thought standard practice was to include 
> > `stout/os/int_fd.hpp` instead of the platform-specific header? That's what 
> > we do everywhere else.

(1) Included `try.hpp` and `unreachable.hpp`.
(2) The pattern I've followed is to include `os/int_fd.hpp` if I'm actually 
using `int_fd`, and using it like an `int`.
    I've included `os/windows/fd.hpp` in Widows specific files, because 
including `int_fd.hpp` and using `WindowsFD` seems wrong,
    and using `int_fd` and using member functions like `type()` seem also wrong.


- Michael


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/54595/#review164277
-----------------------------------------------------------


On Feb. 5, 2017, 6:14 p.m., Michael Park wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/54595/
> -----------------------------------------------------------
> 
> (Updated Feb. 5, 2017, 6:14 p.m.)
> 
> 
> Review request for mesos, Daniel Pravat and Joris Van Remoortere.
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> Introduced an `os::dup` abstraction in stout.
> 
> 
> Diffs
> -----
> 
>   3rdparty/stout/include/Makefile.am 53d04a9b6c4a0d8b35d3c84ef24d619fdb8a2c82 
>   3rdparty/stout/include/stout/os.hpp 
> ed6fec3ac1c1f9dfb0585178401f4b552822a0a1 
>   3rdparty/stout/include/stout/os/dup.hpp PRE-CREATION 
>   3rdparty/stout/include/stout/os/posix/dup.hpp PRE-CREATION 
>   3rdparty/stout/include/stout/os/windows/dup.hpp PRE-CREATION 
> 
> Diff: https://reviews.apache.org/r/54595/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Michael Park
> 
>

Reply via email to