Re: [boost] [MPL] Potential use for multiple sequence types

From: Sean Parent (sparent_at_[hidden])
Date: 2002-08-07 17:07:38

I haven't been able to follow all the recent work on mpl but Mat Marcus
pointed me at this thread. Sorry I'm way to busy to get into this in depth
but I thought this was worth writing up in hopes in would be helpful with
the mpl and/or Loki work.

Awhile ago I used meta-programming techniques to implement an R++ like
system (see <http://www.research.att.com/sw/tools/r%2b%2b/> ). I made
attempts at this both with Loki and mpl and failed. I'm convinced it is
probably doable in either, but I got horribly lost in the complexity of each
solution I tried. What I ended up doing was creating my own small
meta-programming system that mirrored stl containers (I implemented a vector
like structure and a map like structure).

The basic idea was that for each normal function there is an associated
meta-function that returns the associated type.

So there is a begin() function that return a begin iterator of type
begin_type.

There is an at() function for indexing, at<2>() will return the third
element. The type of which is at_type<2>::result...

I also wrote some algorithms. There is a for_each which works on the stored
values. And a for_each_type which just operates on the type of each item and
a find_if and a find_if_type, etc. In short this style of metaprogramming
let me mix meta and generic programming without a major shift in thinking -
and I managed to get an implementation of R++ working fairly well. I could
deal with a the types or the values of a container as needed.

The interface to my vector (tuple would be a better name I suppose) looks
like this (truncated for brevity):

class end_list; // "null" terminator

// cell_end is a metafunction to return the first end_list in a typed_list.

template < class P1 = end_list,
            class P2 = end_list,
            ...
            class P20 = end_list>
class typed_vector
{
 public:
    typedef [typed_list of P1-P20] list_type;
    
    typedef iterator<list_type>  begin_type;
    typedef iterator<cell_end<list_type, list_type::value_type>::result>
        end_type;

    enum { size = cell_size<list_type>::result };
    enum { empty = (size == 0) };
    
    template <int Index>
    class at_type
    {
     public:
        typedef cell_at<list_type, Index>::result_type result_type;
    };
    
// Functions
    begin_type begin()
        { return begin_type(m_properties); }
        
    end_type end()
        { return end_type(m_properties); }
    
    template <int Index>
    typename at_type<Index>::result& at()
    {
        return 
static_cast<find_type<Key>::result>(m_properties).access().access();
    }
    
    typedef begin_type::value_type            front;
    typedef at_type<size - 1>::result_type    back;

    ...
 private:
     list_type m_properties;
};

on 8/1/02 9:26 AM, Douglas Gregor at gregod_at_[hidden] wrote:

> [Usual disclaimer: this post should not be confused with my role as review
> manager]
> 
> At WCGP'02 last month, Michael Burton presented a paper titled "Static Data
> Structures: Reconciling Template Metaprogramming and Generic Programming".
> The most important part of their work, I think, was that they gave a very
> natural way to shift code from using dynamic data structures (STL sequences)
> to static data structures (type vectors), by appropriately overloading STL
> algorithms. The same line of code, e.g.,
> 
> for_each(particles.begin(), particles.end(), DoSomething());
> 
> would call either the normal STL for_each loop for a dynamic data structure
> or, for a static data structure, would fully unroll the for_each loop in the
> typical manner. I think this would be a great syntactic addition for MPL, but
> that's not the point. Back to the "multiple sequence types" argument...
> 
> In their system, they used type vectors instead of type lists, because it is
> easy to specify the _dynamic_ contents of each element. For instance, they
> were working finite element analysis, so they might define the particles in
> the system like this:
> 
> template<int N> struct ParticleArray {};
> 
> template<> struct ParticleArray<0> {
> Neutron particle; ParticleArray() : particle(...) {}
> };
> 
> template<> struct ParticleArray<1> {
> Proton particle; ParticleArray() : particle(...) {}
> };
> 
> // etc etc etc for 10,000 particles
> 
> Anyone want to figure out a typelist equivalent for this static data structure
> with dynamic elements? I can't find a good one, and I think that justifies
> the need for a type vector in MPL. I also think that typelists are
> well-justified, so conclude what you may.
> 
> The proceedings for WCGP'02 haven't been published yet, but I'll try to
> contact the author to get an electronic copy of the paper if anyone would
> like to read it.
> 
> Doug
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
> 

-- 
Sean Parent
Sr. Computer Scientist II
Advanced Technology Group
Adobe Systems Incorporated
sparent_at_[hidden]