Re: [boost] [Boost-users] Subject: Formal Review of Proposed Boost.Process library starts tomorrow

Subject: Re: [boost] [Boost-users] Subject: Formal Review of Proposed Boost.Process library starts tomorrow
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2011-02-07 13:22:24

AMDG

Review part 1, documentation:

* Introduction: eg. should be e.g.

* create_child:
   since the argument is the path to the file, why
   don't you take a boost::path, instead of a string?

* It seems like redirecting a stream to a file should
   be supported.  Maybe it can be done with inherit,
   but it isn't immediately obvious and I'd rather
   not deal with handle::native_type at all.

* There are pistream and postream.  What about
   piostream for completeness.

* Why do you have to pass a native handle to
   pipe's constructor.  Can't it be overloaded
   to take a handle?

* "On POSIX systems you must use the macros defined
   in sys/wait.h to interpret exit codes."

   This forces me to use #ifdefs in my code.  Isn't
   there a way to abstract this better?  At least
   you could wrap the macros and have a trivial
   implementation for windows (WIFEXITED -> true)

* context::setup: The reference specifies boost::function< void()>,
   but this is obviously only true for posix.  It should
   describe the two different behaviors.

* std::string context::work_dir; boost::path?

* boost::iostreams has a file_descriptor class
   that is very similar to handle.

* What is the behavior of find_executable_in_path W.R.T.
   extensions.  On windows, does it use PATHEXT?
   I'd like to see this spelled out explicitly.

* What about file associations/#!xxx for create_child?
   i.e. can I run create_child("script.pl") or do I need
   to use shell?  I can live with it either way, but
   the reference needs to specify it.

In Christ,
Steven Watanabe