Re: [Boost-users] Boost.Process article: Tutorial and request for comments

Subject: Re: [Boost-users] Boost.Process article: Tutorial and request for comments
From: Mathias Gaunard (mathias.gaunard_at_[hidden])
Date: 2009-04-21 10:05:04

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.