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.