On Sun, Mar 27, 2011 at 4:01 PM, Jan Kundrát
[...] 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_ptrboost::process::child (or even scoped_ptrboost::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