Boost logo

Boost :

From: Steven Watanabe (steven_at_[hidden])
Date: 2006-11-16 19:01:02


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 USE_FT_COMPONENTS(z, n1, n2) typedef
ft::parameter_types<TYPE_NAME(n2, n1)>::type CAT(component, n2, n1);

              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

**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.
    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/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

Boost list run by bdawes at, gregod at, cpdaniel at, john at