Jeremy Maitin-Shepard wrote:
- The std::istream/std::ostream interface should be decoupled from the facility for retrieving the file descriptor (int) or Windows HANDLE, to avoid the overhead of allocating a streambuf for those users that wish to access the file descriptor/HANDLE directly or use it with asio. Instead, the std::istream/std::ostream interface to a file descriptor/HANDLE could be provided as a separate, completely independent facility (designed so that exactly the same syntax could be used on both Windows and POSIX), and likewise a separate facility for providing an asio interface to a file descriptor/HANDLE (which also allows exactly the same syntax to be used on POSIX and Windows).
+1 That would be useful in many contexts.
- As was observed in the discussion regarding setting up stdin/stdout/stderr file descriptors on POSIX, it is somewhat tricky to correctly set up child file descriptors. As I believe it is fairly common on POSIX to want to set up child file descriptors other than 0, 1, and 2, it would be best for the library to provide explicit support for this, rather than forcing the user to implement it manually in context::setup. A reasonable interface might be e.g.: context::map_file_descriptor(int child_fileno, file_descriptor_t existing_descriptor);
Potentially this same interface could be used on Windows, with child_fileno only valid in the range 0 to 2 (and with appropriate constants defined), and could thus serve as the lowest level interface on top of which other behaviors like pipe, redirect, etc. could be implemented.
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.
- 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?
- 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. _____ Rob Stewart robert.stewart@sig.com 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.