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. - 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. - 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). - 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. 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. Regards, Roland