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 this: 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 parameter.) 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.Fiber.