Re: [boost] Re: defer call

From: Douglas Gregor (gregod_at_[hidden])
Date: 2001-06-14 07:02:30

On Thursday 14 June 2001 03:43, you wrote:
> > The problem is that a bind library tends to grow uncontrollably and
>
> since
>
> > the 'Bind' part of Lambda is scheduled right after the 'Tuple'
>
> part... you
>
> > get the idea. :-)
> >
> > Identifying a 'simple' bind subset isn't easy, since different
>
> people have
>
> > different needs.
>
> I agree with the uncontrollable growth. A code that performs the
> placeholder substitutions with function composition is already over
> 'simple'. And once that part is done, why not add binding of
> operators, and why not control structures ...
>
> We're cutting LL into smaller pieces. tuples became a separate library
> as it is really quite different concept of binding. It is just a tool
> that LL uses.
> bind wont't become another library, but rather the
> user include features like bind functions, operators, control
> structures separately, and each of these include the core machinery
> to make argument substitution and return type deduction work.
>
> Anyway, I like the idea of making LL and function work together.
> But if we take that step, why confine it to just bind invocations:
>
> If something like this would work:
>
> ostream& print(ostream& o, int i) { return o << i; }
> function<ostream&, int> outputter = bind(print, ref(cout), free1)
> // ref is to make bind store cout as reference
> outputter(1);
>
> why not:
>
> function<ostream&, int> outputter = (cout << free1)
> outputter(1);

It's all the same to Boost.Function.

> One detail that requires thinking is that LL stores some of the bound
> arguments as references.
> E.g. the function object resulting from a lambda expression
> a += free1 holds a reference to a.
> In current LL this is ok, as the function objects cannot really be
> stored for future use, but are constructed and evaluated at the same
> site.
> Now, if we store the function object into a variable,
> there's a fear for dangling references.
>
> int *a = new int();
> function<int&, int> f = (*a += free1);
> f(7); // ok
> delete a;
> f(7); // dangling reference
>
> Cheers, Jaakko

Boost.Function won't be dealing with this. However, I was going to bring up 
the issue soon because a signals & slots library is on the horizon, and the 
issue is pertinent there.

Signals & slots deals with the problem of dangling references, pointers, etc. 
by removing connections when objects die. All of the signals & slots 
libraries I've seen thus far include limited binder libraries (usually just 
something that binds the "this" argument for a pointer-to-member-function) 
and when "this" dies, the connection dies. 

We don't want to do the same for Boost. Binding and deferred calls are 
orthogonal concepts, even for signals & slots. So I need a way to 
(statically) traverse all bound objects in a function object (and all 
contained function objects, etc). Then I can find all objects that are able 
to signal end-of-lifetime so that they can destroy the connection when they 
are destroyed.

Here's a possible interface: the signals & slots library defines a visitor 
class as such:

struct BindLifetimes {
  void visit(slot_base& slot);
  void visit(slot_base* slot);
  template<typename T> visit(T); // some hook for user-defined pointer types
};

The lambda library (or binding library) defines a function that traverses all 
bound objects:

template<typename LambdaFunction, typename Visitor>
inline void traverse_bound_objects(const LambdaFunction&, Visitor);

I need this sort of thing to make signals & slots work well, and of course 
I'm willing to help out on the lambda end to get it done. 

        Doug