On Sat, 28 Aug 2004 12:47:23 +0100, Daniel James <daniel@calamity.org.uk> wrote:
I've come up with an alternative way to invoke the typeof emulations that have been posted. It basically works by defining an iterator over the encoded type. Unfortunately, it can't be used inside a function, and is awkward to use in general, but has the advantage is that it only has to define the call to foo once, which might result in faster compile times.
It could possibly also remove the limit on the complexity of the type. Arkadiy's version would require a some changes to do this, but I think Peder's could quite easily. Although I'm not sure as I've only had a brief look at his version.
I've implemented it as a sort of typedef, which seems like the easiest way to use it.
It's probably easier to understand the code than my explanation, so here it is. It's based on Arkadiy's version in the yahoo groups file section.
#define BOOST_TYPEOF_TYPEDEF_ITERATOR_NAME(Name) \ BOOST_PP_CAT(BOOST_TYPEOF_TYPEDEF_ITERATOR_##Name##_, __LINE__)
#define BOOST_TYPEOF_TYPEDEF_ITERATOR(Expr, Name) \ struct BOOST_TYPEOF_TYPEDEF_ITERATOR_NAME(Name) { \ template <int pos> \ struct iterator { \ typedef boost::mpl::int_< \ sizeof(boost::type_of::foo<pos>(Expr))> type; \ typedef iterator<pos+1> next; \ }; \ };
#define BOOST_TYPEOF_TYPEDEF(Expr, Name) \ BOOST_TYPEOF_TYPEDEF_ITERATOR(Expr, Name) \ typedef boost::type_of::decode_type< \ BOOST_TYPEOF_TYPEDEF_ITERATOR_NAME(Name)::iterator<0> \ >::type Name;
#define BOOST_TYPEOF_TPL_TYPEDEF(Expr, Name) \ BOOST_TYPEOF_TYPEDEF_ITERATOR(Expr, Name) \ typedef typename boost::type_of::decode_type< \ BOOST_TYPEOF_TYPEDEF_ITERATOR_NAME(Name)::iterator<0> \ >::type Name;
Here is an example of it's use:
template <class Op> struct result_of_nullary_functor { static Op op; BOOST_TYPEOF_TPL_TYPEDEF(op(), type); };
struct g { int operator()(); }; BOOST_MPL_ASSERT_IS_SAME(result_of_nullary_functor<g>::type, int);
I like the idea, and it is compatible with the first version of typedef that I implemented. In this version, a function returns the size of element # N in a sequence: sizeof(encode_fn<N>::encode(expr)); The problem with this expression, is that because of the lack of partial template specialization, you have to use functions to deduce the type of an expression, and you have to use sizeof for every step in order to get something sensible out of the function expression: Typically, to deduce a pointer expression, you have to do something like: template<typename U> static typename sizer<encode_indirection<Level-1,U,Types>::value>::type encode(U const volatile*); BOOST_STATIC_CONSTANT(unsigned,value=sizeof( encode((T)NULL) )); The compiler did not like deep nesting of sizeof calls. This caused the compiler to complain after 9 or 10 levels. The solution was to roll out the nesting, so now I have functions returning function pointers: template<typename T,typename Types> typename modifiers<T,Types>::type foo(void (*)(sizer<CV_POINTER>,T const volatile*,Types)); where modifiers<T,Types> deduces the proper function pointer to decode T. In this way, foo(foo(foo_start(expr))) points to the 3'rd element in the expression. I have tested this approach with an expression with the depth 120 and BOOST_MAX_TYPEOF_SIZE 150 (with mindboggingly slow compilation times) and it managed to deduce its type correctly. The problem of my current implementation, is that this is an N^2 process: value_type<sizeof(foo_start(expr)), //Level 1 value_type<sizeof(foo(foo_start(expr))),//Level 2 value_type<sizeof(foo(foo(foo_start(expr)))),Level 3 ...
What would be very nice (but probably unattainable) was to reduce this into an N process. Any suggestions would be most welcome.
-- Peder Holt
I've only tested on the intel linux compiler.
Daniel
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost