member function traits (was: Concept Traits Library)

Hi, Related to this message: John Maddock wrote:
Even if the library doesn't provides an approach that works to define all the concepts, it has a lot of useful things. I also suggested to Terje at least to add the mpl and type traits extensions of the library.
Agreed - in fact I don't see why we can't just add the new traits direct to the type_traits library?
Certainly if someone would like to package these up as direct additions to type_traits (so I don't have to do much!) then I'd certainly look favorably on adding them.
and especially related to the function_traits of the type_traits library. Is there any interest in class member function introspection? According to the current documentation, "function_traits is intended to introspect only C++ functions of the form R (), R( A1 ), R ( A1, ... etc. ) and not function pointers or class member functions.". We have, in our work on Boost.Geometry, the need to have the function_traits also working on class member functions. We first had defined a specific meta-function, only for the purpose of concept-checking. Bruno suggested that using function_traits we can avoid that. So we need it to work on member functions. I did some experiments and it is possible to let function_traits checking member functions as well, and it is easy to incorporate into function_traits. It can then be called, for a member function called "apply" of a (template)class called Strategy, like this: typedef typename boost::function_traits<typename BOOST_TYPEOF(&Strategy::apply)>::arg1_type ptype1; for the first argument (in our case a point type, which is then used in the concept-checking using BCCL, to check if it fulfills the point concept and to feed into this same apply method). Adding member function support only needs two relatively simple additions: 1) a specialization for member functions, like this (here only for a const function with 2 parameters) template <typename Class, typename R, typename T1, typename T2> struct function_traits_helper<R (Class::*) (T1, T2) const> { BOOST_STATIC_CONSTANT(unsigned, arity = 2); typedef R result_type; typedef T1 arg1_type; typedef T2 arg2_type; }; 2) the boost::add_pointer call in function_traits should be avoided for member functions, this can be solved by using a meta-function there: template<typename Function> struct function_traits : public detail::function_traits_helper < typename mpl::if_ < boost::is_member_function_pointer<Function>, Function, typename boost::add_pointer<Function>::type >::type > {}; Experiments are here: http://codepad.org/Qw4Uf1aG So I have a prototype, it seems to work fine and can easily be extended and incorporated. Is there more interest in it, and do the type_traits maintainers find this a good idea? Of is it already somewhere else within Boost (or planned)? Regards, Barend

and especially related to the function_traits of the type_traits library. Is there any interest in class member function introspection?
It's been asked for before but I haven't got around to it: https://svn.boost.org/trac/boost/ticket/2011 I think a separate traits class for extracting the member type from a pointer to member is the best solution here, lets say it's called "remove_member_pointer" (finding a good name is the main stumbling block really), then you could use: function_traits<typename remove_member_pointer<member_function_type>::type>::arity etc The advantage is that remove_member_pointer is a pretty simple trait, useful in it's own right, and then we don't need to mess with function_traits. BTW the problem with extending function_traits is that it operates on function-types, and not on pointers or references to functions, but there is no such type as a "member function", only a pointer to one, so we would end up with different behaviors for member functions and regular ones. Hope that makes sense, John.

Hi John, Thanks for your quick answer. John Maddock wrote:
I think a separate traits class for extracting the member type from a pointer to member is the best solution here, lets say it's called "remove_member_pointer" (finding a good name is the main stumbling block really), then you could use:
function_traits<typename remove_member_pointer<member_function_type>::type>::arity etc
O yes, that would be a good solution too. I'm interested in it.
BTW the problem with extending function_traits is that it operates on function-types, and not on pointers or references to functions, but there is no such type as a "member function", only a pointer to one, so we would end up with different behaviors for member functions and regular ones.
Well, in my view the behaviour would be equal, but they would require just some additional specializations (plus the trick to avoid add_pointer). Actually I don't exactly see why function_traits should not operate on pointers. The function_traits_helper operates on pointers and not on types. So what actually happens is that the user removes the pointer, and it is then added in the function_traits, and specialized on in the details. No problem of course, but you could specialize on function-types AND function-pointers separately to avoid the requirement of using remove_pointer. But, again, a remove_member_pointer, if it can be implemented, would do. Is it already implemented or drafted somewhere? Because we cannot wait to use it ;-) Regards, Barend

I think a separate traits class for extracting the member type from a pointer to member is the best solution here, lets say it's called "remove_member_pointer" (finding a good name is the main stumbling block really), then you could use:
function_traits<typename remove_member_pointer<member_function_type>::type>::arity etc
O yes, that would be a good solution too. I'm interested in it.
BTW the problem with extending function_traits is that it operates on function-types, and not on pointers or references to functions, but there is no such type as a "member function", only a pointer to one, so we would end up with different behaviors for member functions and regular ones.
Well, in my view the behaviour would be equal, but they would require just some additional specializations (plus the trick to avoid add_pointer).
Actually I don't exactly see why function_traits should not operate on pointers. The function_traits_helper operates on pointers and not on types. So what actually happens is that the user removes the pointer, and it is then added in the function_traits, and specialized on in the details. No problem of course, but you could specialize on function-types AND function-pointers separately to avoid the requirement of using remove_pointer.
Nod.
But, again, a remove_member_pointer, if it can be implemented, would do. Is it already implemented or drafted somewhere? Because we cannot wait to use it ;-)
It's here: https://svn.boost.org/trac/boost/browser/sandbox/type_traits/boost/type_trai... John.

But, again, a remove_member_pointer, if it can be implemented, would do. Is it already implemented or drafted somewhere? Because we cannot wait to use it ;-)
It's here: https://svn.boost.org/trac/boost/browser/sandbox/type_traits/boost/type_trai...
Thanks! Barend

On Tue, Jul 13, 2010 at 5:04 AM, Barend Gehrels <barend@geodan.nl> wrote:
Hi,
Related to this message:
John Maddock wrote:
Even if the library doesn't provides an approach that works to define all the concepts, it has a lot of useful things. I also suggested to Terje at least to add the mpl and type traits extensions of the library.
Agreed - in fact I don't see why we can't just add the new traits direct to the type_traits library?
Certainly if someone would like to package these up as direct additions to type_traits (so I don't have to do much!) then I'd certainly look favorably on adding them.
and especially related to the function_traits of the type_traits library. Is there any interest in class member function introspection? <snip> Of is it already somewhere else within Boost (or planned)?
FYI, the Boost Function Types library provides introspection for member function pointers. http://www.boost.org/doc/libs/1_43_0/libs/function_types But I would still be interested in a remove_member_pointer for type_traits. Daniel Walker

Hi Daniel,
Of is it already somewhere else within Boost (or planned)?
FYI, the Boost Function Types library provides introspection for member function pointers.
http://www.boost.org/doc/libs/1_43_0/libs/function_types
But I would still be interested in a remove_member_pointer for type_traits.
OK, thanks! Looking good. Now two alternatives, great. Regards, Barend

Hi,
FYI, the Boost Function Types library provides introspection for member function pointers.
http://www.boost.org/doc/libs/1_43_0/libs/function_types
But I would still be interested in a remove_member_pointer for type_traits.
I tried them both, both approaches work perfect. For use within Boost.Geometry we take function_types because it is an already included library. Thanks again, Barend
participants (3)
-
Barend Gehrels
-
Daniel Walker
-
John Maddock