Boost C++ Libraries

PrevUpHomeNext

8.Project position

8.1. History of changes
8.2. Pending work
  • Relicensed the code under the Boost Software License 1.0only. The first version was available under both this license and the MIT one only to comply with Summer of Code guidelines.
  • The POSIX-specific bits of a child's exit status were split from the status class into a new posix_status class.
  • The status constructor was made private to prevent accidental construction by the user and the create_status function was added to aid in the creation of such objects from custom Child implementations.
  • Initial public release. This is what was presented at the end of the program under which Boost.Process was developed: Google's Summer of Code 2006.

This section contains a list of pending items in the library that should be addressed before it can be sent for a serious/formal review. Some of these are a simple matter of programming but others will require more consideration to decide the best way to solve them.

8.2.1.Code

  • Integrate with Boost.Asio to permit asynchronous notification of child process termination and availability of new data in output streams.
  • Add the ability to force/request the termination of a child process.
  • Make it possible to specify a timeout when waiting for child processes to terminate.
  • Parametrize classes that use strings to support wide characters.
  • Make the detail::launcher_base a public class? It can be useful to end users if they decide to implement a custom launcher.
  • Replace custom system_error with Boost.System's homologous when it is available.
  • Abstract cstdlib's EXIT_SUCCESS and EXIT_FAILURE.
  • Rename command_line::argument method; and add operator<<?
  • Make launcher::start a free function. Need to rename launcher to context.
  • Make child::wait return a constant object.
  • Make status' constructor private.
  • Remove command_line::get_arguments.
  • Separate the executable from the command_line class into its own object.
  • Allow to retrieve a handle for the current process. Need to reintroduce the process class being a parent of child and correct the use of Win32 HANDLEs in the former: they really should be identifiers.
  • Add a Design decisions chapter.
  • Fix links to inherited methods. Don't know which is the best approach to address this.
  • Add some diagrams to illustrate interprocess communication.
  • Shorten "Motivation" section?
  • command_line's constructor: rename firstarg parameter to avoid confusion with subsequent parameters.
  • When process identifiers are fixed under Win32, document that process identifiers are integral types.
Copyright 2006 Julio M. Merino Vidal

PrevUpHomeNext