Re: [boost] Boost.Bind result types

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-10-30 08:26:32

From: <scleary_at_[hidden]>
> I have a request for Peter Dimov.  Before I go any further, just let me
say
> that I only recently began using Bind -- I love it!

:-)

> My request: Can you provide a type generator for bind?  Something on the
> order of:
>   boost::bind_traits<F, R, A0 = void, A1 = void, A2 = void, ...>
>   { typedef ... result_type; };
> or anything similar that can provide some typedef for the result of a bind
> call.
>
> I'd much appreciate it.  BTW, this would apply to mem_fn as well.

A very interesting, and probably reasonable, request. I'll have to think
about it in more detail. In the meantime I suggest that you 'cheat' and use
_bi::bind_t<R,F,L> directly. ;-)

It's telling that bind.hpp does 'cheat' in exactly the same way in the
member function overloads.

However, I strongly prefer that we lobby for "typeof" instead of providing
half-hearted solutions to some aspects of the general problem!

> P.S. The Reason:

... is very important.

> Having recently converted to Function/Bind from Borland
> closures, I was trying to reduce the number of "_" parameters passed to
> bind():
>   t.OnTimer = bind(&X::func, &x); // equivalent to:
>   t.OnTimer = bind(&X::func, &x, _1, _2, _3);
>
> (with Borland closures the above would be "t.OnTimer = x.func;", a much
> cleaner syntax)

So, you think that a special bind overload to support a closure would be a
good thing; something between bind and mem_fn, that preserves the signature
of the member function but stores an object pointer along with it. (As a
side note, I don't think it should be named 'bind' as its semantics are
different. 'closure' perhaps?)

This is a feature that is often requested and reinvented.

But. This is a situation where the tools influence your design. If you start
on a clean sheet, using bind/function from day one, you'll see that this
feature is not so often needed as you previously thought.

The reason for this is that the closure solution forces you to maintain
compatible signatures, i.e. t.OnTimer and X::func must match.

bind doesn't have this restriction. You can design the event interface
(OnTimer) and the implementation (X::func) independently.

A (paraphrased) example from my code:

t.onShow = bind(&X::setVisible, &x, true);
t.onHide = bind(&X::setVisible, &x, false);

--
Peter Dimov
Multi Media Ltd.