Re: [boost] New Library Proposal: dual_state

From: David Abrahams (dave_at_[hidden])
Date: 2005-07-11 07:49:57

"Jost, Andrew" <Andrew_Jost_at_[hidden]> writes:

>  > -----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?

In the CVS at libs/parameter (new docs in progress at
libs/parameter/doc) and boost/parameter.  An earlier version of the
tutorial docs are at
http://cvs.sourceforge.net/viewcvs.py/*checkout*/boost-sandbox/boost-sandbox/libs/utility/doc/named_params.html#tutorial

> 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.  

No, that's approximately 180 degrees away from correct.  Bjarne
Stroustrup used to recommend it, and it appears that a few people
still think it makes sense, but in fact throwing from constructors is
a very good idea because it allows us to establish simple class
invariants.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com