Date: 2002-07-29 02:40:09
Below is my formal review for the Boost MPL Library:
On the whole, I find MPL to exhibit an astonishingly high
level of design; from lambda/bind expressions to familiar
STL-like algorithms, MPL exposes a great amount of power
through a consistent and highly reusable interface.
Overally, I applaud Aleksey for his crafting of MPL's
One facility sorely missing is an mpl::is_sequence query
metafunction. The ability to query an arbitrary type T to
determine whether it is an MPL-compatible sequence will be
of utmost importance in creating flexible class templates.
For example, the desired semantics for the under-development
boost::variant is to allow a simulated variadic template
parameter list *or* a single MPL-sequence. That is to allow
both of the following to exist as valid declarations,
typedef boost::variant<int,double,std::string> my_variant;
typedef mpl::list<int,double,std::string> types;
typedef boost::variant< types > my_variant;
Such an 'overloaded' interface cannot be implemented without
a mpl::is_sequence facility. I discussed the inclusion of
this facility with Aleksey some weeks ago, but I have not
yet seen its appearance in the library; it is vital,
however, that it eventually appears.
Finally, I would like to directly address the question of
sequence-genericity, however, as it seems to be a
significant sticking point for some members of the Boost
community. While I have not yet used any sequence-type other
than mpl::list in my own code (primarily because mpl::vector
has only become recently available), I feel that MPL's
genericity in terms of sequence-types is not detrimental for
the following reasons:
1) Current code demonstrates the value of this genericity:
* mpl::vector offers features not available via "dot-style"
(i.e. mpl::list) sequences, such as random-access to
* mpl::range_c enables large sequences of values to be
represented compactly and efficiently.
* mpl::filter_view and mpl::transform_view allow for lazy
evaluation of sequence filter and transformation operations.
2) MPL's genericity does not come at a terrible price to
those who do not need it. A few "unnecessary" invocations of
mpl::sequence_tag and algorithm traits templates does not
seem to me a terrible price to pay for the genericity
offered by MPL.
(NOTE: I personally used MPL on MSVC7 and GCC 2.95.)
I am *most* impressed that MPL functions with an (almost)
uniform set of features on compilers ranging from Visual
C++, GCC, Metrowerks, Borland (?), and Comeau. I know from
personal experience in template metaprogramming with MSVC
how difficult and frustrating compiler bugs and workarounds
can be. That MPL largely encapsulates these workarounds is a
miracle in itself.
In addition to encapsulating workarounds, MPL is otherwise
well-implemented -- that is, it works as intended. While
its implementation files tend to be complex and difficult to
read, this is primarily a result of dealing with the
above-mentioned compiler bugs. I believe that a pure C++98
implementation of MPL would appear far simpler than the
current, macro-laden version.
Quite simply, I believe that MPL both is impressive in its
capability to deal with broken compilers and stands tribute
to the sorry state of compiler implementations currently on
the market. All in all, I am glad that MPL deals with these
compilers so that I don't have to.
MPL's documentation seems to be the shoddiest part of the
library. This is not to say that it is *bad* -- as that is
far from being the case -- but I feel the following changes
should be made.
MPL has a steep learning curve. I have been using various
version of MPL for the past 6 months, so I am largely past
this curve, but I fear for new users of the library.
Primarily, I think more examples should be provided in the
tutorial, paper, and reference documentation. Currently the
first is limited to simple explanations of mpl::if_ and
mpl::apply_if, the second to somewhat obscure applications
of MPL, and the last to near-trivial uses of the various
algorithms, metafunctions, etc. While I understand that good
documentation is hard to write, and I therefore understand
while it has been long in the coming, I think it will be
important for MPL's ultimate success in Boost.
Please don't mistake MPL's steep learning curve as a sign of
poor design, however. The STL -- a library to which MPL is
(intentionally) similar in design -- surely has a steep
learning curve for new users, yet few will blame the
difficulty of learning STL on poor design.
--- For those who need to do template metaprogramming, MPL will serve invaluable. Before using MPL, I did extensive metaprogramming work without it. There is no way I would consider going back to my pre-MPL days <g>. I wholeheartedly vote for formal acceptance of MPL into Boost (with the hope that my nits, particularly regarding mpl::is_sequence, will be heard and eventually addressed). Thanks, Eric Friedman ebf_at_[hidden]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk