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: 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
>>    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(). 
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();

};

HTH,
Vicente