Re: [boost] New Library Proposal: dual_state

From: Jost, Andrew (Andrew_Jost_at_[hidden])
Date: 2005-07-10 20:47:38

 > -----Original Message-----
> From: boost-bounces_at_[hidden] 
> [mailto:boost-bounces_at_[hidden]] On Behalf Of David Abrahams
> Sent: Sunday, July 10, 2005 10:23 PM
> To: boost_at_[hidden]
> Subject: Re: [boost] New Library Proposal: dual_state
> 
> Eelis van der Weegen <gmane_at_[hidden]> writes:
> 
> > So, in conclusion, the motivation for your dual_state is 
> very valid, 
> > but personally I think Boost.Optional is a more appropriate design.
> 
> IMO the "guaranteed object delivery" feature makes for a 
> useful specialization of the Boost.Optional design.  However, 
> it would be nice to have both; it's not an alternative to 
> Boost.Optional.

I agree.  These are two separate ideas, each with its own utility.

> 
> There's a lot of resonance with the Boost.Parameter library in here.

Where can I find information on Boost.Parameter?

One additional thought occurred to me.  How does Boost.Optional handle
cases where object construction fails?  I'm not sure how many approaches
exist to the problem of failed constructors, but I think most
programmers agree that constructors should rarely (if ever) be allowed
to throw an exception.  Would it make sense for Boost.Optional to detect
failed constructors and consider those objects uninitialized?  Here is a
contrived example:

// -- begin
class construct_status { /* TBD */ };

class foo : public construct_status {
    int *i;
public:
    foo() throw() : i(new(nothrow) int) {
        if( !i ) {
            this->construct_status::set_bad();
        } else {
            this->construct_status::set_good();
        }
    }
};

boost::optional<foo> x = foo();
if( !x ) {
    // end up here if the foo constructor called
construct_status::set_bad
}
// -- end

It seems that if Boost.Optional users must always test for
initialization anyway, we could add a valid object check for free.  I
would be interested to hear what others think about this.

-Andy