From: Hamish Mackenzie (boost_at_[hidden])
Date: 2001-11-25 11:19:21
Looks very cool.
On Sun, 2001-11-25 at 02:30, Andrei Alexandrescu wrote:
> * There is some controversy around the TYPELIST_nn macros. The best solution
> uses an extralinguistic mechanism, which is sort of "cheating" but sounds
> pretty good. I believe that the one true solution is to change the language.
> I am eager to hear suggestions and I would love it if the ensuing discussion
> would lead to a good solution.
Ok firstly I think with the language as it stands the macros are the
best solution. However, they are only the best solution if they can be
used in partial specialization (as this is the area where non macro
solutions fail). As it stands I think the bugfix of adding ::self onto
the end has broken this support.
What compiler/bug does this fix?
Could it be that the compiler is expanding the macros then having
trouble tokenizing resulting '>' characters?
If so an extra white space might help...
#define TYPELIST_2(T1, T2) ::boost::loki::type_list<T1, TYPELIST_1(T2)>
#define TYPELIST_2(T1, T2) ::boost::loki::type_list<T1, TYPELIST_1(T2) >
If that doesn't fix it how about...
#define TYPELIST_2(T1, T2) ::boost::loki::type_list<T1, \
::boost::loki::type_list< T2, ::boost::loki::null_typelist > >
Secondly I have had a bit more of a think about how I would like the
language extension to work and how we can get there with minimum pain. I
have created a header file that contains macros that wrap the
extension. The file also includes wrappers for existing compilers.
Firstly type_list would become a keyword or special type. If used with
angle brackets <> it would behave as it does now. If used with square
brackets  it would behave as follows...
type_list ---> null_type_list
type_list< a, type_list< b, type_list< c, null_typelist > > >
type_list< a, type_list< b, type_list< c, x > > >
The macros that wrap these three cases would be
The program I have attached creates the header file typelistext.hpp
which has all of these macros. It has a switch that we can set when/if
compilers ever support the extension I have described (by defining
You should be able to use this header as a drop in replacement for your
macros (as long as we can sort out the ::self thing).
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk