Boost logo

Boost :

Subject: Re: [boost] [process] Formal Review starts today, 27 October
From: Bjorn Reese (breese_at_[hidden])
Date: 2016-11-13 07:23:47

On 11/07/2016 01:46 AM, Klemens Morgenstern wrote:

> I didn't understand it that way, especially since he Bjorn mentioned
> boost::thread. I'm a bit tired of this discussion, and Boris explained
> very well, why the initializers-approach was chosen. As far as I
> understand it he considers everything but args as attributes and wants
> them all crammed into one type (or something like that) which would be a
> horrific mess. I should know, I tried to build somethinke like that
> (based on boost.process), just two ours ago - it doesn't work for a
> proper process library, there are just too many properties to a process.

"Horrific mess" is in the eye of the beholder.

With the current API it is unclear which parameters are mutually
exclusive (e.g. can I pass both a yield context and an error_code?)
or what happens if I specify the same attribute multiple times like

   bp::child c(command,
               bp::std_out > p,
               bp::std_out > "output.txt");

and of course the argument overwrite issue mentioned by Lee, all of
which demonstrates that the current API is error-prone.

The discussion about attributes is a bit fuzzy because the library does
not define what they are. After a closer look it appears that there are
several categories of attributes crammed into the initializer list.

One such category is the status-reporting (e.g. error_code and yield
context.) Here is another idea for an API: have separate functions for
synchronous and asynchronous invocation.

Let the synchronous invocation accept one command parameter, one
optional attributes parameter, zero or more arguments, and one optional
error_code. The latter determine whether the call throws or not. I am
deliberately omitting the attributes parameter below because it is
irrelevant to the sync/async split.

   bp::system(command, arguments...); // throws
   bp::system(command, arguments..., error_code&) nothrow;

Let the asynchronous invocation accept one io_service parameter, one
command parameter, one optional attributes parameter, zero or more
arguments, and one handler/extension parameter (i.e. no error_code

   bp::async_system(io, command, arguments..., [](error_code){});
   bp::async_system(io, command, arguments..., yield);

This solves the error_code versus yield context issue, and it further
more enables more capable extensions (see my next mail) such as for

Boost list run by bdawes at, gregod at, cpdaniel at, john at