[Boost-commit] svn:boost r64812 - in sandbox/SOC/2010/process: boost/process libs/process/doc

Subject: [Boost-commit] svn:boost r64812 - in sandbox/SOC/2010/process: boost/process libs/process/doc
From: boris_at_[hidden]
Date: 2010-08-15 06:43:55

Author: bschaeling
Date: 2010-08-15 06:43:53 EDT (Sun, 15 Aug 2010)
New Revision: 64812
URL: http://svn.boost.org/trac/boost/changeset/64812

Log:
Updated documentation
Text files modified: 
   sandbox/SOC/2010/process/boost/process/child.hpp            |     2 +-                                      
   sandbox/SOC/2010/process/boost/process/handle.hpp           |     2 +-                                      
   sandbox/SOC/2010/process/boost/process/process.hpp          |    20 +++++++++++---------                    
   sandbox/SOC/2010/process/boost/process/self.hpp             |     3 +++                                     
   sandbox/SOC/2010/process/libs/process/doc/childprocess.qbk  |     4 ++--                                    
   sandbox/SOC/2010/process/libs/process/doc/communication.qbk |     2 +-                                      
   sandbox/SOC/2010/process/libs/process/doc/context.qbk       |     4 ++--                                    
   7 files changed, 21 insertions(+), 16 deletions(-)

Modified: sandbox/SOC/2010/process/boost/process/child.hpp
==============================================================================
--- sandbox/SOC/2010/process/boost/process/child.hpp	(original)
+++ sandbox/SOC/2010/process/boost/process/child.hpp	2010-08-15 06:43:53 EDT (Sun, 15 Aug 2010)
@@ -50,7 +50,7 @@
      * Creates a new child object that represents the just spawned child
      * process \a id.
      *
-     * The \a fhstdin, \a fhstdout and \a fhstderr file handles represent
+     * The \a hstdin, \a hstdout and \a hstderr file handles represent
      * the parent's handles used to communicate with the corresponding
      * data streams. They needn't be valid but their availability must
      * match the redirections configured by the launcher that spawned this

Modified: sandbox/SOC/2010/process/boost/process/handle.hpp
==============================================================================
--- sandbox/SOC/2010/process/boost/process/handle.hpp	(original)
+++ sandbox/SOC/2010/process/boost/process/handle.hpp	2010-08-15 06:43:53 EDT (Sun, 15 Aug 2010)
@@ -74,7 +74,7 @@
      * Constructs a handle from a native handle.
      *
      * This constructor creates a new \a handle object that takes
-     * ownership of the given \a h native handle. The user must not
+     * ownership of the given \a native handle. The user must not
      * close \a native on his own during the lifetime of the new object.
      * Ownership can be reclaimed using release().
      *

Modified: sandbox/SOC/2010/process/boost/process/process.hpp
==============================================================================
--- sandbox/SOC/2010/process/boost/process/process.hpp	(original)
+++ sandbox/SOC/2010/process/boost/process/process.hpp	2010-08-15 06:43:53 EDT (Sun, 15 Aug 2010)
@@ -66,7 +66,7 @@
     {
     }
 
-#if defined(BOOST_WINDOWS_API)
+#if defined(BOOST_WINDOWS_API) || defined(BOOST_PROCESS_DOXYGEN)
     /**
      * Constructs a new process object.
      *
@@ -104,8 +104,8 @@
      * process identifier may have been reused by a different process. It
      * might still be valid, though, if the process has refused to die.
      *
-     * \throw boost::system::system_error If the system call used to
-     *        terminate the process fails.
+     * \throw boost::system::system_error If system calls used to terminate the
+     *        process fail.
      */
     void terminate(bool force = false) const
     {
@@ -130,14 +130,16 @@
     }
 
     /**
-     * Blocks and waits for the child process to terminate.
+     * Blocks and waits for the process to terminate.
+     *
+     * Returns an exit code. The process object ceases to be valid after this
+     * call.
      *
-     * Returns an exit code. The child process object ceases to be
-     * valid after this call.
+     * \remark Blocking remarks: This call blocks if the process has not
+     *         finalized execution and waits until it terminates.
      *
-     * \remark Blocking remarks: This call blocks if the child
-     *         process has not finalized execution and waits until
-     *         it terminates.
+     * \throw boost::system::system_error If system calls used to wait for the
+     *        process fail.
      */
     int wait() const
     {

Modified: sandbox/SOC/2010/process/boost/process/self.hpp
==============================================================================
--- sandbox/SOC/2010/process/boost/process/self.hpp	(original)
+++ sandbox/SOC/2010/process/boost/process/self.hpp	2010-08-15 06:43:53 EDT (Sun, 15 Aug 2010)
@@ -124,6 +124,9 @@
         return e;
     }
 
+    /**
+     * Returns the current work directory.
+     */
     static std::string get_work_dir()
     {
 #if defined(BOOST_POSIX_API) 

Modified: sandbox/SOC/2010/process/libs/process/doc/childprocess.qbk
==============================================================================
--- sandbox/SOC/2010/process/libs/process/doc/childprocess.qbk	(original)
+++ sandbox/SOC/2010/process/libs/process/doc/childprocess.qbk	2010-08-15 06:43:53 EDT (Sun, 15 Aug 2010)
@@ -5,7 +5,7 @@
 [import ../example/create_child_overloads.cpp]
 [create_child_overloads_exe]
 
-The above example will throw an exception of type `boost::system::system_error` if no executable hostname is found in the current work directory. _create_child_ does not automatically search the filesystem for an executable. If you know the executable is not in the current work directory you must add the path (either relative or absolute). 
+The function throws an exception of type `boost::system::system_error` if no executable hostname is found in the current work directory. _create_child_ does not automatically search the filesystem for an executable. If you know the executable is not in the current work directory you must add the path (either relative or absolute). 
 
 If you know the executable can be found in the directories of the environment variable PATH you can call _find_executable_in_path_. This function returns the absolute path to the executable. If it can't find the executable in PATH it throws `boost::filesystem::filesystem_error`. 
 
@@ -15,7 +15,7 @@
 
 [create_child_overloads_args]
 
-If you like to run a command on the shell you can use another free-standing function _shell_. 
+If you like to run a command on the shell you can use another free-standing function called _shell_. 
 
 [import ../example/shell.cpp]
 [shell]

Modified: sandbox/SOC/2010/process/libs/process/doc/communication.qbk
==============================================================================
--- sandbox/SOC/2010/process/libs/process/doc/communication.qbk	(original)
+++ sandbox/SOC/2010/process/libs/process/doc/communication.qbk	2010-08-15 06:43:53 EDT (Sun, 15 Aug 2010)
@@ -10,6 +10,6 @@
 
 [caution You must not call _child_get_stdin_, _child_get_stdout_ and _child_get_stderr_ if you didn't configure the standard streams to be redirected to the parent process.]
 
-The streams returned by _child_get_stdin_, _child_get_stdout_ and _child_get_stderr_ are used similarly to streams from the C++ standard. The type of the return values is either _pistream_ and _postream_ (depending on whether they are input or output streams). These classes are derived from `std::istream` and `std::ostream` and provide two additional member functions `close()` and `handle()`. You use the latter member function for asynchronous I/O. 
+The streams returned by _child_get_stdin_, _child_get_stdout_ and _child_get_stderr_ are used similarly to streams from the C++ standard. The type of the return values is either _pistream_ or _postream_ (depending on whether they are input or output streams). These classes are derived from `std::istream` and `std::ostream` and provide two additional member functions `close()` and `handle()`. The latter member function is used for asynchronous I/O. 
 
 [endsect]

Modified: sandbox/SOC/2010/process/libs/process/doc/context.qbk
==============================================================================
--- sandbox/SOC/2010/process/libs/process/doc/context.qbk	(original)
+++ sandbox/SOC/2010/process/libs/process/doc/context.qbk	2010-08-15 06:43:53 EDT (Sun, 15 Aug 2010)
@@ -7,7 +7,7 @@
 [import ../example/create_child_context.cpp]
 [create_child_context_configuration]
 
-In practice you are probably more often using the member variables `context::stdin_behavior`, `context::stdout_behavior` and `context::stderr_behavior`. It depends on them how standard streams of a child process are configured. 
+In practice you are probably more often using the member variables `context::stdin_behavior`, `context::stdout_behavior` and `context::stderr_behavior`. They are used to configure standard streams for child processes. 
 
 The type of these three member variables is `boost::shared_ptr<boost::process::behavior::stream>`. _behavior_stream_ is the base class of a small hierarchy of behavior classes. Boost.Process provides the following stream behavior classes: 
 
@@ -17,7 +17,7 @@
 * _behavior_named_pipe_
 * _behavior_dummy_
 
-It depends on these classes if and how a standard stream can be used by a child process. As it is a class hierarchy you are free to derive your own classes and [link boost_process.extension_points define new stream behaviors]. 
+It depends on these classes if and how a standard stream can be used by a child process. As it is a class hierarchy you are free to derive your own classes and [link boost_process.user_guide.user_stream_behaviors define new stream behaviors]. 
 
 By default, standard streams are inherited. If you want to configure standard streams differently create an instance of a stream behavior class and assign it. For convenience all behavior classes provide a _behavior_stream_create_ member function which returns an instance of a stream behavior owned by `boost::shared_ptr`.