Re: [boost] [gsoc] Boost.Process done

Subject: Re: [boost] [gsoc] Boost.Process done
From: Jeremy Maitin-Shepard (jeremy_at_[hidden])
Date: 2010-09-10 13:49:12

On 09/10/2010 04:26 AM, Stewart, Robert wrote:

> [snip]

> The problem with the suggested approach is that Windows winds up
> with runtime errors if the child_fileno argument exceeds the
> range.  It would be better to make that a compile time error.
> The only way to do that is to use a template with the fileno
> being a template argument.  Whether that takes the form of a
> fileno class template or the fileno is a template argument for
> map_file_descriptor (which must then be a member function
> template), is another matter.

For POSIX, it would be unfortunate to require the child fileno be 
specified as a compile-time constant.  However, perhaps the interface 
can be constructed so that stdin, stdout, stderr are handled at 
compile-time on Windows (e.g. being distinct types), while allowing the 
same syntax to result in runtime handling on POSIX.

>
>> - I think it would be cleaner for the POSIX and Windows
>> extension interfaces to be in the form of a callback function
>> (templated or boost::function), rather than a subclass of
>> context that overrides the setup function.
>
> Why do you make that assertion?  What becomes cleaner?

For one thing, with C++1x lambdas, it would be more convenient to define 
a function than to define a subclass, particularly if you are making use 
of variable capture.  Likewise, if using boost::bind, boost phoenix, 
etc.  Also, it is unclear if you are supposed to be modifying the 
environment, stream behaviors, etc. from within the setup function, or 
whether they have already been processed (I would guess already 
processed) --- if so, why at such a late stage? --- and if not, why is 
setup a method of context, if none of the state in context is actually 
relevant?

>
>> - It seems that natively on Windows, unlike on POSIX, there is
>> no notion of an array of command line arguments --- there is
>> just a single string command line.  It seems it would be useful
>> for Boost Process to allow a single string command line to be
>> specified directly, in addition to the existing array
>> (Container) interface which presumably does some sort of
>> encoding into a single string on Windows.  Perhaps create_child
>> can simply distinguish (at compile-time) between being passed a
>> range of char and being passed a range of range of char.
>
> A general facility for converting between the two representations
> would be most helpful.  For example, one may wish to report the
> command line, so accessing it as a single string is useful on
> POSIX and Windows systems.  Likewise, one may wish to process the
> arguments one at a time, as with argc/argv, even on Windows.

Possibly that would be useful, though the encoding of an array of 
strings into a single string could be somewhat tricky, and would likely 
need to differ between POSIX and Windows.  On both platforms, you would 
presumably wrap all arguments in double quotes, but the handling of 
quotes and backslashes would differ: on POSIX, you would presumably use 
C-style quoting of quote and backslash characters, which is also what 
most of the shells use.  On Windows, it seems there is a different 
convention, in which backslashes not followed by a quote are not 
interpreted as escape characters, as described at

http://msdn.microsoft.com/en-us/library/17w5ykft.aspx

and

http://msdn.microsoft.com/en-us/library/ms647232.aspx

I'm not sure whether there is any useful convention for 
non-printable/control characters on either platform --- perhaps best to 
leave them unchanged, since they are rare anyway.

However, given that you have to manually invoke a function like 
CommandLineToArgvW to obtain the command-line as an array on Windows, I 
expect that many programs use their own parsing, which may have 
different behavior.