Boost logo

Boost :

Subject: Re: [boost] [gsoc] Boost.Process done
From: Nathan Crookston (nathan.crookston_at_[hidden])
Date: 2011-02-02 01:12:47


Hi Claude,

On Tue, Feb 1, 2011 at 2:37 PM, Claude Quézel <cquezel_at_[hidden]> wrote:
> I noticed that the boost::process::child does not have a default
> constructor. If I have a coding requirements like the following
> example, I would be stuck:

> // Note the required default constructor
> boost::process::child child;
>
> // Create a scope for the mutex guard
> {
> boost::lock_guard<boost::mutex> guard(process_launch);
>
> // Here I must do something within guard scope
> // that must be done with the boost::process::launch
> do_something();
>
> child = boost::process::launch(exec, args, ctx);
> }

The author may have his own reasons for this, but making
process::child default constructable would probably break an
invariant. Some libraries choose to do so and add isValid() member
functions to test for true initialization. In my experience this
leads to lots of testing, asserts, and generally less readable code as
those objects are passed to functions, etc.

In the case you mentioned, you could declare a scoped_ptr<> to the
child, or if you don't want dynamic memory allocations, a
boost::optional<>. This would allow child to keep its invariants and
use a well-known idiom for testing validity.

HTH,
Nate


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk