Re: [boost] Boost.Process 0.5: Another update/potential candidate for an official library

Subject: Re: [boost] Boost.Process 0.5: Another update/potential candidate for an official library
From: Boris Schaeling (boris_at_[hidden])
Date: 2012-11-13 14:38:24

On Wed, 07 Nov 2012 23:29:09 +0100, Vicente J. Botet Escriba  
<vicente.botet_at_[hidden]> wrote:

> [...]I can admit that there could be some extension for specific  
> platforms, but from the documentation it seems that the common part is  
> not enough to make portable programs. Examples are, cleaning up  
> resources, handling errors, the relative path, inheriting env variables,  
> asynchronous i/o, child destructor, return code for wait_for_exit, ...

If you mean with portable programs not having to use #ifdefs in user code,  
then everything in the list above can now be done without #ifdefs. The  
only use case where I can't offer a solution without #ifdefs is waiting  
asynchronously for processes to exit. But then the solution offered is at  
least based on a Boost library.

> The mix of posix and windows specific in class child is really troubling
>
> struct child {
>    // construct/copy/destruct
>    explicit child(const PROCESS_INFORMATION &);
>    explicit child(pid_t);
>
>    // public member functions
>    HANDLE process_handle() const;
>
>    // public data members
>    PROCESS_INFORMATION proc_info;
>    pid_t pid;
> };
>
> Are these really public members?

The constructors allow you to instantiate child if you got process  
information or a pid for example from a third-party library.  
process_handle() is used by wait_for_exit() and terminate(). And proc_info  
and pid are public for convenience. If there is a preference to make the  
member variables private and define accessors - no objection from me.

Thanks for your feedback,
Boris