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::liststd::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#namespa...
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.