Hi David, There is a separate subsection on member pointer operator in the lambda docs. http://boost.org/doc/html/lambda/ le_in_details.html#lambda.operator_expressions The behavior of the lambda ->* mimics the behavior of the built-in ->*. So the lambda functor: (_1 ->* &Class::member_func) == 1 will inside find_if be called as: ((_1 ->* &Class::member_func) == 1)(some-object-of-type-Class) and thus will end up calling: some-object-of-type-Class ->* which will not invoke member_func, but rather expects an argument list (in this case empty). BLL's ->* is defined the way it is for consistency, but it may not be all that useful, at least for the built-in case. Best , Jaakko On Jan 11, 2006, at 11:56 AM, David Greene wrote:

I'm debugging some even nastier lambda compiler error messages (not sure if I can reduce to a testcase but I'll try). In the course of figuring this out, I relized that I need to understand the similarities and/or differences between bind operations and ->* in a lambda context.

What is the difference between these two:

class Class { public: int member_func(void); };

bind(&Class::member_func, _1) == 1

(_1 ->* &Class::member_func) == 1

used in the context of

std::find_if(seq.being(), seq.end(), <lambda-func>);

Does the second construct make sense in this case? I don't think it does because member_func takes no arguments. Because the ->* expression must be followed immediately by an argument list, there is no way to delay the substitution of the object on which to call member_func. This, I believe, it what bind is for.

That is, ->* only delays application of n-1 arguments, where n is the total arity of the function (including the hidden "this" parameter).

Bind is able to delay application of all n arguments.

Is this analysis correct?

-Dave _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users