|
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