Re: [boost] Boost.Process 0.5 released

Subject: Re: [boost] Boost.Process 0.5 released
From: Klaim - Joël Lamotte (mjklaim_at_[hidden])
Date: 2012-08-18 14:27:04

On Sat, Aug 18, 2012 at 8:06 PM, Boris Schaeling <boris_at_[hidden]> wrote:

>
> What exactly do you mean if you compare child with std::thread?

I mean that an instance of std::thread reprensents the thread (executing or
executed), that you can't copy it, you can move it (in C++11) so it can be
contained in a standard (c++11) containers.
Basically if you have a std::thread object (or a boost::thread), then you
can't assume that another part of the code hold the same thread.

I thought that the child class could be designed like the std::thread
because, AFAIK, the design of std::thread forbid a lot of potential errors
by misleading the developer.
Now, as processes are a bit different than threads, I don't know if it
makes sense that child would follow the same design as std::thread,
but my first reaction was to be a bit suspicious. After all, this means
that several child instances can manipulate the same object.

Making it non-copyable would force the user to use shared pointers to
achieve the same, but it would then make it obvious that an instance of
child is the unique representation of a child process, and that if you want
to share it, like std::thread, you have to share references to it in a way
or another, like with a shared_ptr.

I guess it have to be discussed, I don't feel confident in my expertise on
the subject.

>  4. I see that some example use lambdas, so C++11 enabled. Why not use auto
>> too then? I think some of the macro use (related to return types in
>> particular) can be removed by using auto.
>>       Obviously that's true only if the example are meant to use C++11.
>>
>
> Can you give me an example what you are referring to? It's not a macro
> like WEXITSTATUS I guess (as they are POSIX-only)?

Ignore my comment, I think I misread some details of the code.

By the way, in this example:

#if defined(BOOST_WINDOWS_API)
    typedef boost::asio::windows::stream_handle pipe_end;#elif
defined(BOOST_POSIX_API)
    typedef boost::asio::posix::stream_descriptor pipe_end;#endif

    boost::asio::io_service io_service;
    pipe_end pend(io_service, p.source);

Can't there be a utility function that would provide the right type
depending on the target platform?

I mean, any way to avoid users messing with macro would be positive, if
possible.
If this library is proposed to the standard later, removing any macro use
for the user would be mandatory anyway.

Joel Lamotte