Hi, first of all I would like to thank you, Boris for your effort in writing this library. Recently I wrote quite a lot of code where (Boost.)Process would be of great help, provided some things were fixed. As most of the things I would like to be changed were already addressed by the previous posters to this thread, I'm going to use Roland's post (with which I agree 100%) and just add some notes. On Thu, Aug 23, 2012 at 10:18 AM, Roland Bock <rbock@eudoxos.de> wrote:
On 2012-08-18 17:31, Boris Schaeling wrote:
Please have a look at the documentation and think about whether this library could fit into Boost. If you have more time, please download and play around with the new version. Concentrate on the bigger picture: Does the design make sense? Is it easy to understand? Can you do what you want to do? Does it look and feel like modern C++? In reviewing previous mails in this thread I realized that I my comments focused on the examples. I'll give my opinions on your questions here:
- Does the design make sense? Partially: I like a lot of aspects, for instance the initializers, especially bind_stdin and Co. But to be confronted with Windows/POSIX specific stuff for even the simplest tasks, is bad design in my eyes.
+1 + as others said, the special devices/'files' like /dev/null, NUL and friends should be platform independent if possible.
- Is it easy to understand? Yes and no. I mean, hell, yes! Much easier than handling fork and opening pipes on my own. I did that myself and it would be so much nicer using the current version of Boost.Process. But then my current code is POSIX only. If I wanted to write platform independent code, I would still feel lost.
+1 Not to say how lost might feel the people who didn't write the code but have to maintain/bugfix it.
- Can you do what you want to do? Yes and no. Yes, I could replace my own current stuff. No, I want to turn my current code into a platform independent version and I don't know how unless I add a bunch of #ifdefs (and I don't want to).
+1
- Does it look and feel like modern C++? Not to me. I'd expect a modern C++ process library to allow me to write platform independent code where possible. Running a process, knowing the environment, doing IO, waiting for it to finish, knowing the exit code should not require different code and should behave in the same way (e.g. the default environment for child processes should be the same). Of course, if I want to know the child::pid or the child::proc_info and do something with it: sure, that would be platform dependent.
+1 There certainly are differences between POSIX and WINAPI, but for the 95% of cases where you don't have to do special tweaking (handling SIGCHLD differently, etc.) the programmer should not be forced to do the #if-#else dance. This should be kept only for those who want/need to do that, but certainly not the default (simple) usage. Of course the POSIX-specific and WINAPI-specific things from which applications targeted only for a single platform could benefit should stay included (and maybe a couple more added). And, it is nice that there is a lightweight 'handle' to the child process, but I (and IMHO others) would not mind if there was a more heavyweight but also a more powerful equivalent (for example using RAII as others suggested to clean things up properly in a platform independent way).
It is certainly required to allow the library user to perform platform dependent things. But it feels wrong to require the library user to perform platform dependent things.
As a summary: Even though I really think you did a really terrific job in wrapping the fork() and the like for Windows and for POSIX, I would not vote for inclusion into boost since the library user is still required to take a lot of care to write platform independent code. It is too hard to get it right and too easy to get it wrong.
It seems to me that the amount of work required to turn Boost.Process into a library that allows to write platform independent code easily is rather small compared to what has been invested to get it to the current state. It would certainly be worth it.
Same here. Best regards, Matus