[boost] Re: Formal Review: Template Metaprogramming Library (MPL)

From: Eric Friedman (ebf_at_[hidden])
Date: 2002-07-22 01:38:05

I am very glad to see that MPL is finally up for review.

I have been using MPL for quite some time now in various projects
(including Boost.Variant, which is now under development), and it's
served as invaluable to my metaprogramming work.

The review version (mpl_19_jul_02) of MPL, however, has been confusing
me. I am not sure if what I am seeing, however, is the result of changes
since the April version or of bugs in the current version.

For example, I am pleased to discover that lambda mostly works on MSVC7
such as in the following:

  typedef mpl::lambda< mpl::less<_,_> >::type Predicate;
  BOOST_STATIC_ASSERT((
      mpl::apply2<
          mpl::lambda< mpl::logical_not<Predicate> >::type
        , mpl::integral_c<int,7>
        , mpl::integral_c<int,4>
        >::type::value
    ));

However, the above does *not* work on GCC 2.95. I get an error "no type
named `type' in `Predicate'."

Note, however, that removing the lambda-ization from the typedef on the
first line results in successful compilation on both GCC and MSVC.
_Should_ the extra lambda here really break the code on GCC?

Another example: mpl::bind seems to be almost entirely broken in this
release; either that or its semantics have changed so much that I simply
don't understand how it should be used. For the life of me, I can't
determine what is wrong with the following:

  BOOST_STATIC_ASSERT((
      mpl::apply1<
          mpl::bind2< Predicate, _1, mpl::integral_c<int,4> >
        , mpl::integral_c<int,3>
        >::type::value
    ));

As well, I'm not sure to what end the void_ specializations for all of
the MPL metafunctions serve. What _is_ mpl::less<>? Shouldn't the
metafunction class be mpl::less<_,_>? Are users supposed to use the
former? If so, why is there zero documentation to that effect?

Finally, it seems that fold (and its numerous variations) are broken for
iterator_ranges (and types built upon it, such as filter_view and
transform_view); the problem seems to be a result of fold's reliance on
the O1_size algorithm. It appears that either loop-unrolling must
disappear for non-O1_size sequences or that size must be calculated in
O(N) for these sequences, and I'm not sure which is the better option.
As always, please correct me if I am mistaken.

Aleksey, great work on MPL so far; I plan to post my formal review in
the coming days.

Thanks,
Eric