Re: [boost] bind.hpp updated

From: Douglas Gregor (gregod_at_[hidden])
Date: 2001-07-13 10:37:03

On Friday 13 July 2001 10:52, you wrote:
> From: "Douglas Gregor" <gregod_at_[hidden]>
>
> > On Tuesday 10 July 2001 09:38, you wrote:
> > > I've updated bind.hpp. It now supports member function pointers and
> > > accept()s visitors. :-)
> >
> > A few comments/questions:
> >
> > - BOOST_BIND: why? Is this a workaround for MSVC?
>
> Yes. function.hpp indirectly includes type_traits/conversion_traits.hpp. It
> contains a nested class template named 'bind'. This breaks the
>
> boost::bind<R>(f, ...);
>
> syntax under MSVC.
>
> There are two workarounds:
>
> 1. Rename the nested 'bind' class template to something like 'bind_17' or
> 'inner'.
> 2. #define BOOST_BIND to something other than 'bind' and use that instead.
>
> 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. 

> > - accept(): The code invokes the visitor with the bare a1, a2, etc. This
> > means the the visitor may see ref_t<T> or value<T> arguments. Is this
> > intended behavior?
>
> Yes. See bind_test_4.cpp. This allows you to handle references differently.

Okay.

> > If so, ref_t<T> and value<T> must be specified as part of
> > the visitor concept.
>
> Only if your visitor intends to handle them. The 'accept' member is
> primarily to support integration with other libraries, not for the end
> user.
>
> --
> Peter Dimov
> Multi Media Ltd.

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. 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);
};

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

[I'm CC'ing Jaakko because he has dealt with bound objects much more 
extensively than I have, and may have some useful feedback.]

        Doug