On 2012-08-18 17:31, Boris Schaeling wrote:
Boost.Process 0.5 has been released! Documentation and library can be found at: <http://www.highscore.de/boost/process0.5/> Hi,
it is really good to see that this project is continued! Thanks for the effort! Just two weeks ago I needed something like this: Start a child process (shell script in my case), feed it some data via STDIN, read whatever it sends to STDOUT or STDERR, with timeouts and size limits. So basically, your tutorial fits perfectly and I certainly would have used boost::process if it were a boost library already :-) After reading the tutorial and taking a quick look at some of the reference pages, my only concern is that I see blocks like these too often for my taste: #if defined(BOOST_WINDOWS_API) ... #elif defined(BOOST_POSIX_API) ... #endif It is probably good that it is possible to get down to the dirty system specific details if required, but I'd like to be able to handle child processes without thinking about the operating system (unless I want to do something really special). For instance, I like the inherit_env initializer. Does something on POSIX, probably a no-op on Windows. I can just use it and be done with the environment. But things like wait_for_exit seem strange to me: If the library takes care of the forking and handles setting up pipes in such a nice way, why should the user of the library be bothered with the different ways of interpreting the exit information (unless he really, really wants to)? Same with a /dev/null sink. Offering a factory method would be easy and spares the user. Or this one: #if defined(BOOST_POSIX_API) signal(SIGCHLD, SIG_IGN); #endif child c = execute(run_exe("test.exe")); #if defined(BOOST_WINDOWS_API) c.discard(); #endif I understand that the signal stuff is not required for Windows, but why not offer a convenience function that sets the signal handler on POSIX and does nothing on Windows? Same with the discard method. Does something on Windows, does nothing on POSIX, and I get to write code without using the #ifdefs every other line. The other thing about the discard: I think one of the first things I'd do is write a wrapper for child that is non-copyable (as also suggested by Joel) and calls discard in its destructor. I wonder if that should not be part of the library, too? With the probable exception of the asynchronous IO and wait, I think it should be possible to get rid of the #ifdefs in the tutorial. And IMHO that would be a nice improvement for what looks like a cool library already :-) Regards, Roland