Boost logo

Boost :

From: Jost, Andrew (Andrew_Jost_at_[hidden])
Date: 2005-07-14 20:50:36


 

> -----Original Message-----
> From: boost-bounces_at_[hidden]
> [mailto:boost-bounces_at_[hidden]] On Behalf Of Rob Stewart
> Sent: Thursday, July 14, 2005 9:53 PM
> To: boost_at_[hidden]
> Cc: boost_at_[hidden]
> Subject: Re: [boost] New Library Proposal: dual_state
>
> From: "Jost, Andrew" <Andrew_Jost_at_[hidden]>
> > From: boost-bounces_at_[hidden]
> > [mailto:boost-bounces_at_[hidden]] On Behalf Of Rob Stewart
> > > From: "Jost, Andrew" <Andrew_Jost_at_[hidden]>
> > > > > From: boost-bounces_at_[hidden]
> > > > > [mailto:boost-bounces_at_[hidden]] On Behalf Of Fernando
> > > > > Cacciola
> > > >
> > > > Here is a real example. Imagine a researcher with many
> > > > instruments
> > > >
> > > > 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
> > >
> > > 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.
>
> 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?
>

But I never gave any indication that we can change the library at all!
Not even to use the adapter. The adapter is a function object that
returns exactly what the library function expects.

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

The Boost.Optional::adapter syntax is its own predefined library and,
though lambda is a fantastic approach, it won't compile using Microsoft
so we can't say it's the new paradigm.

> > > 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.
>
> It was your idea, and now you're questioning it? I take from
> that the responses you've gotten have caused you to rethink
> not just the approach, but the idea?
>

Not at all. I would distrust anyone who has total faith in the
usefulness of a new idea such as this one. The need for another opinion
is why forums such as this one even exist.

> > > 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).
>
> There's no need. As I pointed out, the adapter can hold its
> own T instance which represents the default. Then, when
> asked for a value (returned by reference), the adapter
> queries the optional.
> If the optional has a value, the adapter returns the
> optional's value. If not, the adapter returns the default
> value it holds.
>

I considered that approach. It could be used to return only const
references, which may or may not be enough.

-Andy


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk