Boost logo

Boost :

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

Boost list run by bdawes at, gregod at, cpdaniel at, john at