From: Thomas Wenisch (twenisch_at_[hidden])
Date: 2002-07-18 12:09:35
On Wed, 17 Jul 2002, Douglas Gregor wrote:
> The formal review for Aleksey Gurtovoy's Template Metaprogramming Library
> (MPL) begins today and will continue until Monday, July 29th.
Hello Aleksey, Doug, all,
I am very excited to see the MPL library reach review! I have been using
a home-brewed mix of pieces of Loki and my own partial specialization
madness for some time, and I am looking forward to see what can be
accomplished if one approaches the problem of template metaprogramming
I am starting with my review of the documentation. I hope to get to the
code within a few days.
Here are my comments on the MPL paper:
The permutations example used in section 1.3 of the paper is described as
a "simple" example. However, the code is fairly complex, and uses a
number of tricks which I would describe as advanced uses of STL. For
example, the use of &*in to obtain the parameter for std::copy.
Additionally, the comment reads
// return an array of the N! permutations of x
However, the function returns all N! permutations of the array in, x does
not appear in all_permutations.
More importantly, the example of permuting an array strikes me as fairly
esoteric, and does not motivate template metaprogramming very
strongly. I understand the pedagogical advantage of starting with
factorial as the canonical example of functional programming, and then
building from there throughout section 1. However, an example that
accomplishes something more familiar to "everyday" programming would be
Unfortunately, I don't have anything better to suggest right now. Anyone
else have any ideas? I will think about this some more and see if I can
give a concrete suggestion, but I think a better example would make the
paper more accessible.
One thing I would suggest, though, is to mention the FSM example from
section 5 early on in the introductory material. Section 5 is a great
demonstration of the power of MPL-enabled code generation. I think
mentioning this problem as motivation in section 1 would be a good way to
make the problems that metaprogramming solve more concrete for the
Here are some grammar corrections and minor suggestions for the paper. No
more technical comments below this point.
The acronym EBNF should be spelled out on first use.
first sentence: "... one of the basic concept ..." should read " one of
the basic concepts" The rest of the first paragraph is somewhat run-on,
and should be rewritten.
second paragraph: " ... first to introduce the compile-time sequences of
types ..." should read " ... first to introduce compile-time sequences of
1st sentence: " ... Boost Metaprogramming Library operates on ..." =>
" ... Boost Metaprogramming Library operate on ... "
2nd sent: " For example, searching a type ..." => "For example,
searching for a type ..."
2nd para, last sentence: " the semantics is very close, there are
... " => " the semantics are very close. There are ... "
The first paragraph talks about the various Sequence concepts in
MPL. You explicitly define Sequence in terms of begin<> and end<>, and
then describe the refinements of Sequence in terms of XY Iterator
requirements. However, these requirements are not defined and may not be
obvious to the reader, since they are similar in spirit, but certainly not
in syntax to the STL equivalents. I suggest you give an example of an
additional requirement each concept adds, for example, something like the
" ... a Forward Sequence is a Sequence whose iterator satisfies the
additional Forward Iterator requirements (ie next<> advances the
I actually see that you do exactly what I ask for after the tiny_list
example. I suggest moving this up above the example.
Remove the word "So," from the beginning of the paragraph.
second to last para: "But, from user's perspective..." => "But, from
the user's perspective ..."
later in same para: " So, for the convenience purposes, .." => "So, for
start of second para: remove the word "expression." at the beginning.
following the exmple using bind< : "or to use compose_ family of
templates an similar way." => "or to use the compose_ family of templates
in a similar way"
In the last three examples of 3, the int_c<> wrapper around 16
disappeared. Is this intentional?
Computer Architecture Lab
Carnegie Mellon University
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk