Boost logo

Boost :

From: Mat Marcus (mmarcus_at_[hidden])
Date: 2001-11-28 12:40:59

Let me put on my customer hat for a moment. First let me thank Andrei
and Aleksey for their efforts. This stuff is really promising. I see
two potentially interesting and useful libraries being discussed. As
I wrote in an earlier post a number of issues must be addressed
before achieving successful reuse in a corporate shrink-wrap
development environment. One issue which tends to be under-emphasized
is documentation.

On the one hand we have Loki. Andrei's library is innovative and well
known, and his book on use, implementation, and modern C++ techniques
is extraordinary. With Loki I could tackle many real world technical
problems. I could also use the book for training engineers and
managers. Unfortunately, Andrei has not chosen to support the
Microsoft compiler. This renders Loki nearly useless in our
environment. Some of us are working to address this, but this remains
as a huge stumbling block.

On the other hand we have boost::mpl. From initial examination mpl
looks really interesting. I suspect that I will learn a great
studying mpl, both from the meta-STL design style and the
implementation techniques. And the compiler neutrality appears to be
in place. Until recently, however, I have seen little or no
documentation. Please keep it coming. I can not stress how important
this is, especially in the metaprogramming domain. There are more
than a few who argue that us template folks are insane :-). I can't
tell if mpl will be useful in the near future or not simply by
looking at the code.

Some questions:

* What are we after here? Are we discussing whether to adopt
something like Loki::typelist in its current form and replace the
implementation later with the more general mpl? If so what price will
we pay in terms of implementation readability? It's simply not true
that boost users can remain unaware of implementation details.

* Are we aiming for the "best interface/implementation however long
it takes" or is there room for a staged approach where we adopt
something that is proven now, but maybe break compatibility later?
If we adopt an interface other than Loki's what price will we pay in
terms of documentation quality?

* If we reimplement the boost smart pointers in terms of Loki, and we
reimplement Loki typelists in terms of mpl, does that meant that
application programmers have to be mpl/Meta-STL aware when debugging
simple scoped pointers?

* I would like to see some more concrete discussion. General
philosophizing about the merits of different libraries has a low
signal to noise ratio. We have to consider both interface and
implementation. For example, could we shed some light on the mpl
interface by looking at some example code/use cases? Perhaps some of
Andrei's typelist applications could be rewritten in mpl to give us a
better feel for mpl's idioms. I would also be interested in seeing
some examples illustrating any of the facilities that Dave mentioned
in an earlier post:

At 7:59 PM -0500 11/27/01, David Abrahams wrote:
>1. Algorithms can be used with different compile-time sequence structures
>and implementations
>2. Function composition
>3. Argument binding
>4. A far-thinking design for metafunctions which will probably allow a
>meta-lambda facility
>5. Lifts the need for the user to deal explicitly with loopn termination in
>a separate piece of code (the specialization).
>6. A convenient way to specify type lists without macros

  - Mat

Boost list run by bdawes at, gregod at, cpdaniel at, john at