On Wed, 07 Nov 2012 23:29:09 +0100, Vicente J. Botet Escriba <vicente.botet@wanadoo.fr> 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