Re: [boost] [process] Formal Review starts today, 27 October

Subject: Re: [boost] [process] Formal Review starts today, 27 October
From: Klemens Morgenstern (klemens.morgenstern_at_[hidden])
Date: 2016-11-07 08:11:14

Am 07.11.2016 um 13:43 schrieb Lee Clagett:
> On Sun, 6 Nov 2016 09:30:18 +0100
> Klemens Morgenstern <klemens.morgenstern_at_[hidden]> wrote:
>
>> Am 06.11.2016 um 01:39 schrieb Lee Clagett:
>>> On Sat, 5 Nov 2016 17:15:58 +0100
>>> Bjorn Reese <breese_at_[hidden]> wrote:
>>>   
>>   [...]
>>   [...]
>>   [...]
>>> I'm glad you brought this up - I think Niall did as well - if you
>>> look at the constructor documentation for `process::child` it is
>>> very bare. And I am not sure how to easily describe how to use it.
>>> I think maintainability is going to be difficult without a more
>>> strict contract of expected arguments and behavior.
>> That is because it is one of the three launch functions, but their
>> are actually quite clearly defined. You either pass a known type that
>> will be intepreted as some property (i.e. std::string->args) or you
>> pass a property directly, i.e. args+="Value". That is quite clear,
>> but it is extensible, hence the list of actually allowed types are
>> written in the reference at the properties, not in a central list.
> Is the following clear:
>
>      bp::child("foo", "arg1" bp::stdout < bp::null, bp::args="arg2");
>
> Does the last constructor argument clear all `argument properties` used
> by the child? Would this try to invoke process "arg2"?

This would not compile for other reasons. But if you put a bp::args=... 
somewhere it overridesprior arg-setters; that's why you'd use 
bp::args+=.... But that only overrides args, not exe, so if you write 
"bp::child("foo", "arg1", bp::args="arg2") it would call "foo arg2".