Re: [boost] bind.hpp updated

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-07-13 10:58:43

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:

namespace boost
{
    namespace _bi
    {
        template<class R, class F, class L> class bind_t;
    }
}

struct Visitor
{
    template<class R, class F, class L> void operator()(bind_t<R, F, L>
const & b)
    {
        b.accept(*this);
    }

// handle other types here

};

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

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

> [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? :-)

--
Peter Dimov
Multi Media Ltd.