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-10-31 06:21:54

Am 31.10.2016 um 02:53 schrieb Gavin Lambert:
> On 31/10/2016 14:13, Klemens Morgenstern wrote:
>> Ou, that's even worse, with a chain as proposed by Bjorn, it could've at
>> least be a compile-time construction, but you want that actually all
>> built at runtime. This discussion was held many times before, so please
>> don't take this as a personal attack, but here are my reasons this would
>> be the worst design decisions:
> [...]
>> It might look more natural but it just doesn't solve the problem at
>> hand; you have an idea of what you would want to do with the library and
>> you know how that should look. But I cannot assume I know every
>> use-case, that's why there are so many parameters (and they might become
>> more in future versions, i don't know). If you want you solution it will
>> take about 30 lines to implement it using boost.process.
>
> That's a fair point, although with arguments I would expect there to be
> runtime overhead anyway.  I think it would be exceedingly rare to not at
> least have some parameters passed via variables, and relatively common
> to have some that are entirely conditional as shown in my example.

Sure there's runtime-overhead and starting processes is not the fastest 
thing your os provides. But: you only pay for what you use, that's the 
main goal.

>
>>> Variadics are cool, but they contribute to code bloat, since each
>>> unique sequence of parameter types requires generating a new overload,
>>> and they require templates, which precludes private implementation.
>>
>> Well I trust my optimizer with the code-bloat; if you have several
>> similar use-cases you can just do that exactly one thing: build a small
>> class, which constructs your process; if you have something that does
>> not change a type (like args), that would not cause a problem; and if
>> you want to optimize that, you can just use "extern template".
>
> I mean that these:
>
>   spawn("foo", "bar", "baz", bp::std_out > stdout);
>   spawn("foo", bp::std_out > stdout, "bar", "baz");
>   spawn("foo", "bar", bp::std_out > stdout, bp::args += {"baz"});
>   params = {"bar", "baz"}; spawn("foo", bp::args = params, bp::std_out >
> stdout);
>
> would all generate unique implementations, despite being logically
> equivalent (and then even more implementations if you make the
> redirection conditional too, or have differing argument counts).  Yes,
> you can avoid this if you're paying attention and using a consistent
> style, and the compiler inlining *might* save you even if you don't, but
> it's a trap for the unwary.

Sure, that is always possible. That's a trade-off, but the upside is, 
that only what you use get's compiled in. So the code for this is quite 
small, if you of course have multiple times using a full asio system, 
then it might get critical. But then: if you had this not templated, 
you'd have the asio code always.
>
>>> On a related note: given a variable number of arguments in a
>>> container, how would I pass this to the existing launch functions?  I
>>> don't see an example of this in the docs, and this seems like the most
>>> common case.
>>
>> It has an extra overload for std::vector, and if no other overload is
>> known it tries to use it as a range. I.e. this would work:
>>
>> std::list<std::string> args;
>> bp::args+=args;
>>
>> There isn't any example of this, but it's written in the reference:
>> http://klemens-morgenstern.github.io/process/boost/process/args.html#namespaceboost_1_1process_1args_set_var_value
>>
>
> Then I recommend explicitly mentioning this in the tutorial.  As I said,
> I think this is likely to be a fairly common case in anything that does
> "real" work.
>
Makes sense. I just expected a user to look into the reference after 
seing the args initializer. The tutorial is meant to give you an 
overview. And actually the better style would be:

fs::path exe = foo;
std::vector<std::string> args = {"bar", "42"};
bp::child c(exe, args);

But this only works with std::vector and std::initializer_list.

>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>