From: Ron Garcia (garcia_at_[hidden])
Date: 2002-07-31 22:39:52
The following is my formal review of the Template Metaprogramming
Library. I vote Yes, that the MPL be accepted into boost. I base my
results on reading through the reference documentation, reading the MPL
paper, trying several examples, and replacing metaprogramming constructs
I have used elsewhere with MPL components.
I tend not to delve too deeply into template metaprogramming. As a
result, I find that MPL's simpler components, such as if_, if_c, and
apply_if meet the majority of my needs. Introducing a central and
publicly visible set of relatively routine metaprogramming constructs to
boost is a boon in and of itself. Compile time ifs, etc. located in
various detail namespaces can hopefully be deprecated and replaced with
MPL analogues. In my personal experience, replacing my own
metaprogramming code with MPL constructs has led to somewhat shorter
code that better expresses my intent. The first side effect is nice,
but the second I find more important.
A great aspect of the MPL IMHO is that the algorithms are factored into
separate headers. As a result, one need not import a large header
library to use one metaprogramming construct.
As discussed throughout this review period, the documentation is still a
work in progress. Reference pages need to be completed for all library
components, and more tutorial material needs to be made available. In
addition, more thorough test cases need to be added to the library test
suite. I believe that the current documentation will be a solid
framework that can be filled in during the coming weeks. Aleksey has
made a concerted effort to update the documentation, add missing pages,
which suggests to me that the MPL reference documentation in the least
will reach completion soon. I have seen testing strategies for the MPL
discussed and I hope to see results in that regard soon as well.
Some discussion has ensued regarding terminology, such as "metafunction
class" vs. "quoted metafunction" vs. "metafunctor." My personal
favorite is the last, metafunctor, due to the analogy to STL functors.
Since this library covers new ground and not one of the above
possibilities is clearly superior, I presume that Aleksey will follow
his personal taste and that users will eventually catch on to the
With respect to a need for multiple sequence types (vectors, lists,
etc.) and an STL-like design, I am not yet convinced that such a model
is necessary for a metaprogramming library. Perhaps in the near future
performance numbers will be posted for different compilers and some
light brought upon the topic. In the meantime, the MPL provides an
interesting platform for exploration. Andrei and others have raised
interesting and important questions about how metaprogramming can best
be pursued and what real-world advantages MPL will bring to the table
compared to previous work on metaprogramming libraries. I believe that
time and experience will supply some answers to their questions, and I
do not find their worries ample reason to prevent adding MPL to Boost.
Rather, I think it offers a grand opportunity for some adventurous folk
to seek the answers to these important questions.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk