Re: [Boost-users] Issues with boost::process from the sandbox and the boost::process::child semantics

Subject: Re: [Boost-users] Issues with boost::process from the sandbox and the boost::process::child semantics
From: Dominique Devienne (ddevienne_at_[hidden])
Date: 2011-03-28 12:24:43

On Sun, Mar 27, 2011 at 4:01 PM, Jan Kundrát <jkt_at_[hidden]> wrote:
> [...] For technical reasons (got to do some postprocessing to the
> user-supplied arguments before I actually launch my process), I can't
> initialize the childProcess in the initializer list before the actual
> constructor body, which means that the compiler will have to initialize
> it to something for me. It turns out that the boost::process::child
> class is missing a default constructor

Why not do your arg-processing in a static function returning a new
args vector by value? That way you can initialize Process(...) :
childProcess(..., preprocess(args)) {...}

Or simply using a shared_ptr<boost::process::child> (or even
scoped_ptr<boost::process::child>) instead of a boost::process::child
value, to delay creating the actual boost::process::child instance to
after the initializer? Sounds more logical to me than using
boost::optional. I don't see the lack of a default constructor as a
design flaw here. --DD