From: Andrey Melnikov <melnikov@simplexsoft.com>
Rob Stewart wrote:
From: "Jost, Andrew" <Andrew_Jost@mentor.com>
But you're assuming that we have control over the library. That's probably the exception rather than the rule in real life.
If you can change the library to use an adaptor for an optional, why can't you change the library to use the optional directly?
Adapters work outside the library and don't require any changes to the library. Library requires underlying values, and with the adapter it gets them automagically. The library doesn't know anything about Optional and adapters, library clients do.
Any function that expects a value can be given either a default or the value in an optional just as easily as an the value from an adapter. However, if the library code retrieves the value itself--which is what I meant by the need to change the library code--then it must know that the type is now an adapter or optional.
There is a key advantage in the example with adapters because the adapter is a function object. In that respect, the door has been flung open to many templated constructs that are more difficlt with the ?: operator. For example, a boost::transform_iterator could be created with the adapter to automatically access the underlying objects in a sequence.
Hmmm. This reminds me of using the STL algorithms before having Boost.Lambda, Boost.Bind, etc. Without a library of predefined function objects that perform useful, reusable adaptations, or a lambda approach to creating the adapters, one winds up separating the value extraction logic from the context in which it is used.
Do you mean that efforts to create a custom function object aren't worth of the result, and most people will just end with using IFs and refusing to create an adapter or a function object for an existing adapter?
Yes.
So far I think we can live with just Optional and OptionalWithDefaultValue. A default value is needed very often.
I'm not sure about OptionalWithDefaultValue. It depends upon how it works and what it imposes on its parameterizing type. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;