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

Subject: Re: [boost] Boost.Process article: Tutorial and request for comments
From: Boris Schaeling (boris_at_[hidden])
Date: 2009-04-25 11:48:19

On Tue, 21 Apr 2009 23:21:14 +0200, vicente.botet  
<vicente.botet_at_[hidden]> wrote:

> [...]I will organize the specific classes on a specific platform  
> namespace
> common for the portable part
>
> namespace process {
> namespace common {
>     class process;
>     class child;
> }
>
> posix for the posix based OS
>
> #ifdef BOOST_PLATFORM_POSIX // or something like
> namespace process {
> namespace posix {
>     class process : public common::process{...};
>     class child: public common::child{...};
> }
> }
> #endif
>
> window for the micosoft OS based platforms
>
> #ifdef BOOST_PLATFORM_WINDOWS // or something like
> namespace process {
> namespace windows {
>     class process : public common::process{...};
>     class child: public common::child{...};
> }
> }
> #endif
>
> // other platforms
>
> and have typedef  or a using directive at the namespace process level  
> for each one of the available classes as
>
> namespace process {
> #if defined(__POSIX__) // or something like
> typedef posix::process process;
> // or using posix::process;
> #elsif defined() // other patforms
> ...
> #else
> typedef common::process process;
> or // using common::process;
> #endif
> }
>
> When the user use a non portable feature on a portable programm it will  
> need to check conditionally for the non portable feature as
>
> #ifdef BOOST_PROCESS_HAS_SPECIFC_FEATURE_1
> // ...
> #else
> // ...
> #endif

I see. Thanks for the suggestion! I don't know if this design has been  
considered by the original developers or if they had good reasons to  
reject it and go with the current design. The problems with Boost.Process  
really seem to be unique as too many features are platform-dependent. I  
don't know any other Boost library which had to face similar problems.

> [...]If the command fails it can be recovered
>
> Commands could be composed using pipe "|",
>     shell::cat("/tmp.file.txt") | shell::wc();
>
> redirection ">"
>
>     shell::cat("/tmp.file.txt") | shell::wc() > str;
>
> tee
>
>     shell::cat("/tmp.file.txt") | shell::grep () | shell::tee("file");
>
> conditional concatenation "&",
>
>     shell::cd("/tmp") & shell::ls();
>
> which executes ls only if cd /tmp succeeds.

Another nice idea! However I'm pretty sure that I unfortunately won't be  
able to work on this in the near future given the amount of more  
fundamental problems. :-/

> [...]Last some minor questions:
> What about renaming handle by native_handle?

I'm open to it. You want native_handle to be a first-class citizen? Then  
it should move out of the detail namespace, too?

> What is wrong on using the Boost.Filesystem library to idientify  
> executables?

Support for boost::filesystem::path could be added, too. However it  
doesn't solve the narrow/wide string problem if that's what you meant?

> Why the do we need to duplicate the name of the executables as an  
> argument?

There's no way to distinguish otherwise if the first argument is the  
executable name or if it's meant to be the first command line argument.  
Currently Boost.Process simply copies all arguments into the array which  
is passed as a parameter to main(int argc, char *argv[]).

> Respect to relative or absolute path of executables,why not let the  
> undelying platform to handle with this?

Then developers would need to resolve paths themselves (or use a helper  
function) if they want to write platform-independent code?

Boris

> [...]