Re: [boost] Boost.Process 0.5 released

Subject: Re: [boost] Boost.Process 0.5 released
From: Roland Bock (rbock_at_[hidden])
Date: 2012-08-23 04:18:48

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