Boost logo

Boost :

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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at