Hi Perhaps this would have been better as two separate mails but since it is all lambda related I have included it as one (despite one patch actually being to the result_of library). [lambda] I discovered recently that member-function-ptrs wrapped in boost::lambda objects do not apply directly if the subject is held in a smart-ptr (unless that smart-ptr has an implicit conversion to T*). There are a number of places in our code base where we have worked around this by using something like *free1 rather than simply free1 which ends up calling the 'apply member-function to object-by-reference' adaptor. This works providing the smart-ptr defines a type 'element_type' to be the underlying object type (as shared_ptr et al do). It does not work for third-party smart-ptrs that do not define this type. It struck me that since boost.bind uses boost.mem_fn's get_pointer template to handle this use case it would be reasonable to add an overload of 'apply' to lambda/detail/function_adaptors.hpp that deferred to that. I knocked up a perl script which adds the necessary overloads to each specialization in function_adaptors which I have attached (I have also attached the resulting diff). It may be that this yields some unpleasant side-effects that I haven't thought of or observed but so far it seems to work okay with our code base. The get_pointer overload is disabled if the argument is convertible to ref-to-const-object-type (e.g. if it is a derived type) since then the reference overload should be used. I would appreciate any feedback on the idea and implementation. [result_of] Whilst implementing a front-end template for a set of functions that accept boost.function objects with various return types, I discovered that boost.result_of does not implement support for the nested sig<tuple> template used by boost.lambda objects. My intent was to accept any user-supplied function at the front-end and, based on the given function's return type when applied to a specific set of arguments, forward to the appropriate implementation. This determination currently fails if the user supplies a lambda object. The attached result_of patch adds detection of the nested sig template in order to support determining the return type of lambda functions (providing the necessary arguments are given). This is done in a non-intrusive way; i.e. there is no physical dependency on boost.lambda or boost.tuple, though the boost.tuple classes 'cons' and 'null_type' are forward declared. Since they are only ever instantiated when a boost.lambda object is provided (which will have already brought in their definitions) I think it should be okay. In order to provide the sig template with its required tuple, a facility has been added (with implementation generated by some additional preprocessor code) that converts from function-type to tuple (i.e. F(A,B...) -> cons<F,cons<A, cons<B,...null_type>>>). Since only the type declarations are required this can be done without pulling in any tuple headers. One thing I am a little concerned about is that the determination mechanism for the existence of the sig template is probably not very portable (I have only tried it on GCC 4 and VC9). Is there an MPL/type_traits predicate generator for portable nested template detection? I am aware of BOOST_MPL_HAS_XXX_TRAIT_(NAMED_)DEF but I couldn't see any generator around that area that would do nested template detection. We have such a facility in our code base but it will have only been tried on GCC 4 and VC9 (maybe also VC7.1). Again I would appreciate any feedback on these diffs and whether or not they are suitable for inclusion into the respective libraries. Regards, Adam