-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Rob Stewart Sent: Thursday, July 14, 2005 3:34 AM To: boost@lists.boost.org Cc: boost@lists.boost.org Subject: Re: [boost] New Library Proposal: dual_state
From: "Jost, Andrew" <Andrew_Jost@mentor.com>
From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Fernando Cacciola
Here is a real example. Imagine a researcher with many instruments [snip long example indicating that using Boost.Optional for data collection works fine, but for using or reporting that information, Boost.Optional falls short]
Okay. This works, but what about that ugly call to loadPoint? The problem is that the library function is expecting a signal value, not a Boost.Optional! Boost.Optional helped us manage data collection, but does not help us call trend::loadPoint. Let's look at another example.
The library can just as easily expect a Boost.Optional.
But you're assuming that we have control over the library. That's probably the exception rather than the rule in real life. <clip>
translation point is where I see the need for guaranteed object delivery, for it seems that Boost.Optional and guaranteed object delivery are two ends of the same pipeline: at the head, we obtain (or fail to obtain) a value, and in the process escape the need for a signal value; at the tail, we use the values we've obtained, possibly in a context that EXPECTS signal values. Requires them. So far we've used only the trinary operator to perform this translation, but is there a better way?
The fundamental issue seems to be that you want an object or function that automagically produces a value, even if one wasn't otherwise available.
Yes. <clip>
Using adapters, the call to trend::loadPoint in the first example might look like this:
// -- begin // call trend::loadPoint opt_dp::adapter f(-1); for( data_set::iterator p = d.begin(); p != d.end(); ++p ) { tr.loadPoint( f(*p) ); } // -- end
Your version, with Boost.Optional was like this:
for( data_set::iterator p = d.begin(); p != d.end(); ++p ) { tr.loadPoint( *p ? p->get() : -1 ); }
(I think you could change "p->get()" to "**p" if you like, BTW.)
The latter is simpler and seems far more direct and, therefore, readable. I don't see that your adapter has added any value.
I tried to make the examples as syntactically plain as possile; they are optimized for clarity. 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. <snip>
I don't really see the value as presented thus far. There is a tiny amount of syntactic sugar, but is that warranted?
I'm not sure.
But, why do I keep saying optional instead of Boost.Optional? To see, we must think about how an adapter interacts with the optional object on which it operates. I won't spell out the fairly obvious point that adapters should return references rather than whole T objects, but if this is so, then an adapter that operates on an empty optional object must ask that optional to, first, construct a new T object, then return a reference to that new object. Based on this, we can say a few things about an optional object, X, on which an adapter operates:
(a) X must have valid EMPTY and FULL states. (b) There must exist for X a valid EMPTY state, S, in which X privately holds an object, x, of type T. (c) If X is EMPTY (including state S), then altering or replacing the internal x without setting the state to FULL is a "const this" operation.
Your requirements are flawed. The adapter should hold an instance of type T as provided by the constructor. Then, if the Boost.Optional has no value, the adapter can return it's default instance. IOW, the adapter shouldn't impose its needs on the optional type. Boost.Optional would then work fine, though I still question the value of your adapter.
I would also like to see the adapter avoid "imposing its needs" on the optional object, but conversely, I don't think it would be right to to return whole T objects (instead of references).
-- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer; _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost