[boost] Re: An alternative typeof macro

From: Daniel James (daniel_at_[hidden])
Date: 2004-09-02 04:25:38

Peder Holt wrote:
> My guess is that implementing a linked list, and searching for the
> element at position N would require less compile time.
> Alternatively, make your own vector type, with a predefined
> BOOST_TYPEOF_LIMIT_SIZE number of arguments. mpl::vector is a general
> type vector with many advanced features. All you really need is to
> know the integral value at position N.

Using mpl views might be better. Currently the implementation works by 
passing a list/vector to encode and adding to it. Instead encode could 
just return the sequence for it's sub-type, which can then be combined 
using mpl::joint_view, or similar.

For example, in the current implementation:

     template<class V, class T> struct encode_type_impl<V, const T>
     {
         typedef
             typename encode_type<
             typename detail::push_back<
             V
             , mpl::int_<CONST_ID> >::type
             , T>::type
             type;
     };

Would become something like:

     template<class T> struct encode_type_impl<const T>
     {
         typedef boost::mpl::joint_view<
             boost::mpl::single_view<mpl::int_<CONST_ID> >,
             encode_type<T>
         >;
     };

The big advantage here is that if T has already been encoded (even as 
part of a completely different type) it can be reused. For example if 
the following were encoded:

     std::pair<int, int>
     std::pair<std::pair<int, int>, std::pair<int, int> >

The existing versions would encode std::pair<int, int> 3 times, this 
would do it once.

Another advantage is that the templates would be less deeply nested than 
with a list. It's also a bit cleaner to implement.

I hope that makes sense. I was playing around with this idea a little 
while ago, but didn't quite finish it. I might have another go in the 
future (I'll wait for Arkadiy's new version) if no one else does. If you 
do want to try, you should probably wait for the new version of mpl, 
which will fix a bug that causes problems here.

By the way, in the above example joint_view is probably a little too 
complex. Something like this can be used instead:

     template<class Seq, class T>
     struct push_front_view
     {
         struct begin {
             typedef boost::mpl::forward_iterator_tag category;
             typedef T type;
             typedef typename Seq::begin next;
         };

         typedef typename Seq::end end;
     };

Daniel