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

Subject: Re: [boost] [gsoc] Boost.Process done
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2010-09-10 14:06:53

Jeremy Maitin-Shepard wrote:
> On 09/10/2010 04:26 AM, Stewart, Robert wrote:
>
> > 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'm not sure if there is a nice solution for both sides of the fence, but I agree that a compile-time constant for POSIX would be a pain for most use cases.  Maybe there can be a std_handle class template that is supported on both platforms while the more general, runtime fileno-based variant, is only available on POSIX.  Then, developers can choose to use the portable, but restricted std_handle or the non-portable, but unrestricted general type.

> >> - 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.

Excellent point.

> 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?

That, obviously, could be addressed by documentation, but using the Template Method Pattern would ensure correct sequencing.  If that's still insufficient, then it may be that the various configuration steps should be handled in less monolithic classes.

> >> - 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.

You raise interesting issues.  Windows gives the ability to convert a single string command line to argc/argv using the function you mentioned, so that would, presumably, do the right thing for that platform.  Going the other way is less obvious.

On POSIX, it is pretty straightforward.  One could optimize the output by not quoting arguments without special characters, of course.

There's no need for format portability between platforms, just code portability.

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer, Core Software      using std::disclaimer;
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.