Boost logo

Boost :

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

On 31/10/2016 04:39, Klemens Morgenstern wrote:
> Am 30.10.2016 um 14:21 schrieb Bjorn Reese:
>> The bp::child object should not execute in the constructor, but rather
>> via operator(). That way we can use the named parameter idiom to build
>> up redirections and similar modifications. For example:
>> auto compile = bp::child("c++").output(bp::null);
>> compile("main.cpp"); // Executes

+1 for me for that style too.

> I personally don't like that approach though it certainly would work. I
> think it's partly a matter of taste, here's my (C) association:
> struct X {int std_in; const char* exe;};
> X x{.std_in = 2, exe ="stuff"};
> I.e. your setting properties.
> Now the problem I see is this: what happens here?
> auto compile = bp::child("c++");
> compile.output(bp::null);
> compile("main.cpp");
> compile.env({"PATH", "/foo"});

The fourth call should fail (and probably throw), since it's impossible
to change the environment after the process has been started. Otherwise
that should work as you'd expect.

One of the great advantages of this style of construction is that it
permits conditionals in a fairly natural fashion:

auto compile = bp::child("c++");
if (quiet)
if (debug)
compile.args("-DFOO", filename);
for (auto lib : libraries)
     compile.arg("-l" + lib);
auto child = compile();

or something like that. Or you could have a factory function that
returns the un-executed builder to the caller to add additional
parameters before finally actually executing it, which aids in

> So in order to do that, we'd need a child_builder class, that can be
> converted, similar to boost.format. I consider this style pre C++11,
> i.e. before variadics. Now granted: it seems not very C++ish, but it's a
> very unique problem: most properties are inaccesible after you launched
> the process, which is the reason they are not members.

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.

For something like this, using them seems like the wrong style to me,
and a fluent builder seems like a better approach. But this path might
contain bikesheds.

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at