Re: [boost] Re: loki::type_list == boost::mpl::list_node

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2002-04-17 14:55:20

----- Original Message -----
From: "Emily Winch" <emily_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Thursday, April 18, 2002 12:26 AM
Subject: Re: [boost] Re: loki::type_list == boost::mpl::list_node

>  > I also don't by the argument that typelists are not the only useful
> compile-time
>  > sequence.  Given the tools for meta-programming that we have, all
> other types of
>  > meta-data (besides types themselves) can be stored in a
> 'list-of-types'.  That
>  > is part of the principle of your meta-function classes.
>
> I think this is something that we simply don't know yet (OK, to remove
> the generalisation: I don't know it yet). Containers that come
> immediately to my mind as potentially useful are a tree, and an
> associative container (for making named template parameters out of!).
> It's  possible that nobody would ever want to iterate over a tree, or
> reuse the algorithms in MPL on a tree. It's possible that it's better to
> make an associative container with a typelist of pairs of types.
> Personally I'm not convinced of that, and even if it were to be the
> case, I'm glad the MPL gives me the tools to find this out.
>
> Emily.

There are several reasons why different containers aren't analogous to their
runtime counterparts.  First of all, the typical runtime implementation of
linked-lists are useful primarily because they don't require copying the entire
list.  In the case of compile-time lists, that is the only thing you can do
given the functional environment.  You must 'copy' all of the elements.  To
address some your examples specifically, an associative container is simply a
list of key value pairs--they don't have to be organized, though you could do
that too.  It isn't difficult to produce an implementation to access types by
some other key type:

struct key_1 {
    typedef int type;
};

struct key_2 {
    typedef double type;
};

typedef TYPELIST_2( key_1, key_2 ) assoc_types;

void f(double) {
    std::cout << "void f(double)" << &std::endl;
    return;
}

void f(int) {
    std::cout << "void f(int)" << &std::endl;
    return;
}

int main() {
    type_at<index_of<assoc_types, key_1>::value>::type::type x = 0;
    f(x);
    return 0;
}

As far as a tree goes, I agree that this could be useful.  However, I think the
implementation of it can be included in the basic implementation of a
typelist--simply by assuming that some_typelist::head could be a typelist.  With
that assumption, you can write the algorithm accordingly.

Paul Mensonides