Boost logo

Boost :

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2002-04-10 21:19:10


----- Original Message -----
From: "joel de guzman" <djowel_at_[hidden]>

> PS> Dave, I would love to see a synopsis of all the available
facilities

Aleksey and others are working on it.

> as well as an overview of the overall structure of the library to
visualize
> how much we will pay in order to use a certain facility.

I'm not sure what you would have to see in order to get a sense of that.
Probably performance measurements are the only appropriate avenue, and
you should expect those to vary widely across compilers.

> A technical reference would be really helpful in understanding MPL
more.
> In particular, I'd like to know more about MPL's engine detached from
the
> STLish interface.

Huh? What do you think comprises an "engine?". To draw an analogy, does
the STL have an "engine"?

> I think this is what interests me most. If this engine is
> exposed as a standalone unit along with a reasonable interface (and of
> course with documentation how to use it), this *is* the core library
> that I was alluding to in my previous post.

What functionality would you like to see delineated in this separate
unit?

> I bet it can be reused to power
> other metaprogramming libraries such as well.

Like the STL, the MPL derives most of its power from the fact that it
provides a conceptual framework. When you peel away all the layers, what
you have (as with the STL) are some powerful concept definitions. In
MPL, some of the concepts are:

    metafunction
    metafunction class
    iterator
    sequence

Honestly, I can't see why anyone thinks there is something
non-fundamental/alien-to-FP about algorithms like find_if et al. Every
functional language I've ever seen has such a thing, or quickly grows
it.

-Dave


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk