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