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

Subject: Re: [boost] [process] Formal Review starts today, 27 October
From: Edward Diener (eldiener_at_[hidden])
Date: 2016-11-13 09:15:27

On 11/13/2016 8:54 AM, Klemens Morgenstern wrote:
> Am 13.11.2016 um 13:23 schrieb Bjorn Reese:
>> 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.
> I'm talking about the implementation, not of the usage. Please prove me
> wrong, but with an implementation not an usage-example.
> If you find a solution which can be integrated into boost.process, I'll
> add it to the library.
>>
>> 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");
>>
> Well this will use the second pipe, though I grant you, that's not the
> best solution here - an error would be better.

Whatever you decide it is important to document.

> I could add an assertion,
> so there are no duplicates of that. On the other hand it is similar to
> that:
>
> child_builder cb;
> cb.std_out(p);
> cb.std_out("output.txt");
>
> So it's not that strange.
snipped...