[boost] Re: MPL/lambda question

From: Arkadiy Vertleyb (vertleyb_at_[hidden])
Date: 2003-11-13 17:40:27

Hi Aleksey,

Thanks for your response.

> They are all lambda-enabled, yes, but on a conforming compiler so is any
> other class template (given that it has 5 or less type template
parameters).
> BOOST_MPL_AUX_LAMBDA_SUPPORT is needed only for broken compilers - see
> http://tinyurl.com/uo0z.

I see.  So you use totaly different, non-intrusive mechanism (through
partial specialization and template template parameters?) on conforming
compilers...  Cool.  Now I understand why gcc didn't complain about the same
code.

> BOOST_MPL_AUX_LAMBDA_SUPPORT is only a partial workaround; there are some
> cases when it doesn't work (at least without some extra tweaking), and
> 'select...' templates are one of these cases (the details are usually not
> worth one's time, but if you are really interested, see
> http://tinyurl.com/uu8t). If you have to care about broken compilers...

We probably do, since we are writing a library...  When we started about two
years ago, we made it one of our first priorities to support VC6.  I am not
sure if it is still as relevant.  And it takes lots of effort to overcome
all these "duplicate comdats" and "internal structure overflows"...

> I
> would recommend you to use 'bind' and 'select1st's metafunction-class form
> instead:
>
>     typedef apply2<
>           bind1<select1st<>,_2>
>         , char
>         , pair<int,bool>
>         >::type res;
>
>     BOOST_MPL_ASSERT_IS_SAME(res,int);

Ok.  I already implemented my own workaround by supplying needed typedefs on
top of a select1st parameter, (like select1st<add_first_typedef<_2> >), but
I will discard it, and use this instesad.

A couple more questions:

1. It looks like, while some of meta_functions, like select1st, have
built-in defence from ETI, the others, like push_front, don't ( I had to
write it myself for push_front).  Is it just an overlook, or is there any
reason behind it?

2. To make my transition to MPL easier, I started by modifying our typelist
to become a conforming MPL sequence.  I was able to successfully use some of
MPL algorithms on it (like "fold" family, "find", etc.).  However, to be
able to use mpl::equal, I had to make "next" and "type" typedefs available
on my end() iterator.  Is it how it should be?  Here is our list (I do
intend to get rid of it after all meta-programming code is converted):

 // null_iterator

 struct null_iterator
 {
  typedef boost::mpl::fwd_iter_tag_ category;
 };

 // null_type

 struct null_type // used to be a real null-type before converting to mpl
 {
  typedef null_type head;
  typedef null_type tail;
  typedef null_iterator begin;
  typedef null_iterator end;
  typedef void tag;
 };

 // list

 template<class List> struct list_it;

 template<class Head, class Tail = null_type>
  struct list
 {
  typedef Head head;
  typedef Tail tail;
  typedef list_it<list> begin;
  typedef list_it<null_type> end;
  typedef void tag; //what should I use here?
 };

 template<class List>
  struct list_it
 {
  typedef typename List::head type;
  typedef list_it<typename List::tail> next;
  typedef boost::mpl::fwd_iter_tag_ category;
 };

Thanks,

Arkadiy