Re: [boost] New Library Proposal: dual_state

From: Calum Grant (calum_at_[hidden])
Date: 2005-07-16 05:52:33

> > I've been following this dual_state vs optional discussion for a 
> > while. It seems to me that one should really have a policy 
> class that 
> > defines the default behaviour when the value is unassigned.  This 
> > policy should define whether to
> >
> >   - throw an exception
> >   - construct an object on the fly
> >   - return a default 
> >   - return a null pointer
> >   - whether to return by value or by reference
> >
> > A second point, can't all this be achieved by adding 
> policies to smart 
> > pointers?
> 
> Whoa; smart pointers and boost::optional are not very closely 
> related beasts.  

I mean, a weak_ptr and optional both have 0 or 1 pointees, so there is
at least a passing resemblance.  In the absence of Boost, I would
probably use a std::auto_ptr to store an optional field, which is, um, a
smart pointer.  I realize that Optional is implemented slightly
differently.

> If you add enough policies to std::list you 
> could probably handle this use case, too.  I don't think 
> finding something to policy-ize is always the best way to fit 
> new designs into an existing framework.

Agreed.  Having one uber-pointer that handled everything isn't really
the Boost way, and from a practical perspective there's no point
reworking all of the pointers.  So it was more a "compare and contrast"
than a practical suggestion. 

[As an extreme example,

        container<std::string, set> data1;
        container<std::string, vector> data2;

is probably silly, but has certain merits.  For example you could supply
a sensible default containment policy, and it deemphasises the details
of the containment mechanism.  Of course then the policy does most of
the work and we are back to square one, and in this example there is no
sensible default containment policy (although vector would be a
candidate).]

But my original point still stands: since there are alternative
behaviours for Optional, a standard pattern in this circumstance is to
configure these via a policy, and since C++ templates are zero overhead,
it would add flexibility at no cost.  The alternatives (e.g.
return-by-value) do have run-time overhead.

Policies are also good for optimization.  I mean if you have an optional
int, storing it in-object is fine, but if it is a large object that you
need seldomly, an out-of-object storage policy would be more
appropriate.

But is there sufficient need for different policies in Optional?
Perhaps not.  If it's not broken don't fix it.

Calum