Re: [boost] bind.hpp updated

From: Douglas Gregor (gregod_at_[hidden])
Date: 2001-07-13 11:39:29

On Friday 13 July 2001 11:58, you wrote:
> From: "Douglas Gregor" <gregod_at_[hidden]>
>
> > > I prefer (1), but if the maintainers of the other libraries that use
>
> 'bind'
>
> > > as a common name for a nested class template don't want to change their
> > > implementations, (2) remains an option.
> >
> > Ugh.
>
> Indeed. I've already patched my boost. :-)
>
> > Right, but there still needs to be separation between libraries, and the
>
> end
>
> > user might have their own function object that contains a bound member. A
> > visitor such as ref_visitor from bind_test_4.cpp should not depend on the
> > underlying binding library.
>
> The visitor does not need to depend on the bind library being used, it only
> has to know about it:

That's a dependency :) 

At the very least this sort of customization has to be taken out of the 
visitor, or if it is to be in the visitor it should be in a base class that 
all visitors are expected to derive from.

[code snip]

>
> I've considered providing bind_fwd.hpp for this but for reasons I can't
> recall decided against it. :-)
>
> > Perhaps just common class templates reference and
> > value (each with a get() member to return a reference to the actual
>
> object)
>
> > could be used to distinguish the two. Then the visitor concept looks
> > like:
> >
> > concept binding_visitor {
> >   template<typename T>
> >   void operator()(reference<T>& ref);
> >
> >   template<typename T>
> >   void operator()(value<T>& val);
> > };
>
> boost::ref_t is intended to be the common reference - the tuples library
> had it in a sub-namespace and it was disabled under MSVC by default, so I
> promoted it to 'boost' status. :-)
>
> value<> can be pulled into 'boost' as well; in the boost namespace the
> names are a shared resource so I normally avoid reserving them for my own
> needs.
>
> :-)

True. Perhaps there is a greater need for ref_t and value that I can't come 
up with at the moment. Shouldn't the naming be consistent? ref_t and value_t 
or reference and value?

> :
> > And to avoid the need for visitors to handle function objects directly, a
> > namespace-level function visit_bound_objects. Then bind.hpp would add a
> > function template:
> >
> > template<class R, class F, class L, typename Visitor>
> > void visit_bound_objects(boost::_bi::bind_t<R, F, L> const & b,
> > Visitor& v)
> > {
> >   b.accept(v);
> > }
> >
> > The default definition for visit_bound_objects would do nothing, of
>
> course.
>
> > Other binding libraries could also add function templates
>
> visit_bound_objects
>
> > for their own function object types. If everyone is careful it would be
>
> safe
>
> > even to use multiple binding libraries together (i.e., visiting
> > bind(bind1st(&foo, a), b) would  visit both a and b).
>
> OK, but in a similar situation to the above, will the bind.hpp call of
> visit_bound_objects find the other definition (the one that's supposed to
> handle bind1st_t)? Isn't this too fragile?
>
> The alternative is, indeed, to have visit.cpp depend on the binding
> libraries that it explicitly recognizes and knows how to handle. True, this
> means that your visitor will not automagically handle 'unknown' libraries.

For any Boost library it likely won't be fragile, because visit.hpp will 
theoretically exist in Boost, and even if I only have enough time to grunt 
"visit.hpp" I'll be begging binding library authors to add support for it.

Non-boost libraries are more of a problem. If support for visit.hpp isn't in 
the library, the user would have to write it in a separate header. Then if 
that visiting header is not included but the library headers are, the visit 
operation will silently skip over objects bound by those functions (ouch!). 

Having visit.hpp include support for all known libraries won't be as fragile. 
I can't say that I like that sort of coupling, but the idea of silent errors 
frightens me to the core (dump).

> > [I'm CC'ing Jaakko because he has dealt with bound objects much more
> > extensively than I have, and may have some useful feedback.]
>
> Isn't Jaakko a boost member? :-)

Well, yes, but I'm hoping he'll feel a stronger urge to butt in if I'm 
begging for some insight. :)

> --
> Peter Dimov
> Multi Media Ltd.

        Doug