Boris Schaeling wrote:
I've been looking at the big picture finally trying to find out where and how Boost.Process should be changed and in which direction it should move to become a complete library one day. As not everyone will read the entire article here are my thoughts:
1) Boost.Process is based on a few concepts like 'process' and 'context'. While those make sense there are other concepts where I wonder if they should be dropped:
Here are a few opinions:
* 'executable' is the executable name which in practice must be a std::string. I think the original idea was to support numerous string types. This leads to the question how to support different Unicode encodings which I think is still unanswered in the Boost community. Other libraries, eg. Boost.Interprocess, simply stick to one string type (typically std::string).
I assume the name of the executable should be in the locale character set. So std::string, or even const char*, appear suitable. Now, if you want to perform automatic translation from unicode to locale character set, why not, but that's another layer on top of that. An unicode string type should be convertible to the locale character set easily enough so that you don't need to that in your library, however. You could eventually add support for wide characters, though. While wide characters are Unicode on Windows, they are as far as C++ is concerned just another locale character set, and I think considering them as nothing more than that is best. As far as I know, POSIX systems simply don't have APIs for wide characters, however.
* 'handle' is the underlying native file handle of a stream (file descriptor on POSIX systems, handle on Windows). The concept is based on a class in the detail namespace of Boost.Process. There is just one class and it's not meant to be used by users of the library either. Thus I'm not sure what's the benefit of having an explicit 'handle' concept at all.
Isn't it in case Boost.Process doesn't implement the features I need, so that I may use them directly with the native functions?
3) Currently Boost.Process is really only useful for creating child processes. It's not possible for example to detect and iterate over other processes on a system. I guess Boost.Process should be enhanced here. Then one day the well-known utility 'ps' on POSIX systems could be implemented in Boost C++. Any comments?
I personally think this has pretty low priority.
8) There is a method wait() which makes it possible to wait for another process to exit. Currently wait() is provided by the class child though. Shouldn't it really be defined by the class process (so you can wait not only for child processes to exit)?
How can you wait for something else than your children, assuming there is no "ps"-like functionality?
9) As wait() blocks an asynchronous alternative should be provided.
Definitely.