AMDG I'm not sure whether function_types is ready now or not. I don't really like the tags. Dividing the parameters into two groups (the type arguments and everything else) doesn't seem like the cleanest solution. Even with them it will sometimes be necessary to and_<> several predicates together mpl::and_<is_function<F>, mpl::equal_to<arity<F>, mpl::int_<1> > > so I think making certain properties should not be treated specially. I think that components should probably integrate all the properties a little better. Instead of making it the union of a tag and an mpl sequence would it be better to make it more like mpl metaobjects with appropriate mutators: typedef components<void(int, char)> c; typedef set_result<c, bool>::type c1 typedef set_param<c1, 0, const int&>::type c2; typedef make_variadic<c2>::type c3; typedef get<c3>::type f; // is bool(const int&, char, ...) (Although maybe set_param is asking too much since I don't see the corresponding operation in mpl.) and querying metafunctions: typedef is_variadic<c>::type b; //inherits from mpl::false_ These could be overloaded to take callable builtins too, but that might cause too much overhead translating back and forth between two representations. For both components and the synthesis metafunctions, having the result type as the first element of the sequence doesn't really make sense to me. I would expect that the return type would often need to be handled separately from the parameters in the cases where anything other than simply passing the result of components to function_type<...> is needed. I would like a way to find out what a tag is composed of. I saw represents<> in the code but it isn't documented (unless I missed it) I compiled the following on all the compilers I have with different values for N_TYPES. note that this only uses one partial specialization #include <boost/function_types/components.hpp> #include <boost/function_types/result_type.hpp> #include <boost/function_types/parameter_types.hpp> #include <boost/preprocessor/repetition/repeat.hpp> #include <boost/preprocessor/cat.hpp> #define N_TYPES ... namespace ft = boost::function_types; template<int N> struct Y {}; #define TYPE_AT(n) Y<n> #define CAT(a, b, c) BOOST_PP_CAT(a, BOOST_PP_CAT(b, BOOST_PP_CAT(_, c))) #define TYPE_NAME(n1, n2) CAT(type, n1, n2) #define FUNCTION_TYPE(z, n1, n2) typedef void TYPE_NAME(n2, n1)(TYPE_AT(n2), TYPE_AT(n1)); #define OUTER(z, n, data) BOOST_PP_REPEAT_##z(N_TYPES, data, n) #define NESTED_REPEAT(macro) BOOST_PP_REPEAT_1(N_TYPES, OUTER, macro) NESTED_REPEAT(FUNCTION_TYPE); #define USE_FT_COMPONENTS(z, n1, n2) typedef ft::parameter_types<TYPE_NAME(n2, n1)>::type CAT(component, n2, n1); NESTED_REPEAT(USE_FT_COMPONENTS); msvc 8.0 debug w/o debug N_TYPES time pp time pp 0 1 1 1 1 5 2 1 1 1 10 3 1 2 1 20 10 1 8 1 40 98 2 87 1 msvc 7.1* debug w/o debug N_TYPES time pp time pp 0 2 2 2 2 5 3 2 2 2 10 3 2 2 2 20 17 2 15 2 40 39** 2 37** 2 *I had to use -D"BOOST_FT_CONFIGURATION_OK" **fatal error C1204: compiler limit : internal structure overflow codewarrior 9.2 N_TYPES time pp 0 1 1 5 2 1 10 2 1 20 3 1 30 9 2 40 29 2 A few minor things. pp_tags/master.hpp BOOST_STATIC_CONSTANT(bits_t, combined_bits = LHS_bits ^ RHS_bits ^ (LHS_bits & RHS_mask) ); works but seems obscure to me would (LHS_bits & ~RHS_mask) | RHS_bits be clearer? Here are the mistakes I made when I looked at the documentation initially. If no one else runs into these don't worry about it. It's probably just me. I thought ClassTransform applied to all the parameters not just this. I didn't realize that components was a tag. I saw the capitalized and linked MPL <../../../../../mpl/index.html> - Front <../../../../../mpl/doc/refmanual/front-extensible-sequence.html> / Back <../../../../../mpl/doc/refmanual/back-extensible-sequence.html>Extensible <../../../../../mpl/doc/refmanual/extensible-sequence.html>Random Access Sequence <../../../../../mpl/doc/refmanual/random-access-sequence.html> of all component types and missed the trailing "... and property tag " In Christ, Steven Watanabe