From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-11-26 07:29:11
From: "Andrei Alexandrescu" <andrewalex_at_[hidden]>
> I just uploaded typelist.zip for review. It contains three header files
> a cpp test file.
> 1. Header null_typelist.hpp
> class null_typelist;
> * Defines a class that is used by convention as a typelist terminator. I
> didn't use boost::tuple's null_type because in the long haul, if typelists
> will be accepted, it would be more logical that tuples depend on
> and not vice versa.
Agreed. We already had this discussion on the list before but I'd like to
> 2. Header type_manip.hpp
> template <int v> struct int2type;
> * Maps integral constants to values. As I'm sure you know, this little
> template has a lot of uses. Exposes value which evaluates to the passed-in
> template <typename T> struct type2type;
> * Maps each type to a unique, insipid type. Exposes T as original_type.
> template <bool flag, typename T, typename U> struct select;
> * The well-known "compile-time if". It is present in mpl as well as in
> detail/select_type.hpp. By this I am making a suggestion to give
> "compile-time if" full boost citizenship - not as a member of a library or
Indeed, the compile-time if is already present in a number of boost
libraries. My only concern is that I'd never be able to remember that a
compile-time if is defined in a header called type_manip.hpp.
> template <class T, class U> struct type_list;
> * Guess what :o).
Have you considered using std::pair as the 'dot pair' type? It doesn't
really matter which template is used as long as it has two type parameters -
it doesn't even need a definition. std::pair is handy since it automatically
maps a value list (a tuple) to a typelist.
Unless you need to pass _instances_ of typelists around, of course. Is there
such a need?
> namespace tl
> template <class TList> struct no_duplicates;
> * There is some controversy around the TYPELIST_nn macros. The best
> uses an extralinguistic mechanism, which is sort of "cheating" but sounds
> pretty good. I believe that the one true solution is to change the
> I am eager to hear suggestions and I would love it if the ensuing
> would lead to a good solution.
Why did you reject the make_typelist<...>::type approach?
A general comment about the library: there is significant overlap between
the proposal, the existing tuple library and the upcoming mpl. I'd like to
see this addressed - somehow.
-- Peter Dimov Multi Media Ltd.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk