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.