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...