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

Subject: Re: [boost] [process] Formal Review starts today, 27 October
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2016-10-30 21:53:55

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.

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

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