Boost logo

Boost :

Subject: Re: [boost] Boost.Process 0.5: Another update/potential candidate for an official library
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2012-11-13 14:57:36

Le 13/11/12 20:38, Boris Schaeling a écrit :
> 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.
Could you then update the documentation so that there are no such
dependencies on the underlying platform?
> 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.
Yes, I see that Boost.Asio has not reached to provide a platform
independent abstraction (I'm wondering how this feature appear in the
proposal to the standard C++ committe). Any way, could you explain why
do you need to use a non portable feature?

>> 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().
This can be hidden as an implementation detail (use of friend).
> 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.
You could define a implementation defined native_handle typedef

struct child {

   typedef platform-specific-type native_handle_type;

    // construct/copy/destruct
    explicit child(native_handle);

   native_handle_type native_handle();



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