Boost logo

Boost :

From: Augustus Saunders (infinite_8_monkey_at_[hidden])
Date: 2003-01-09 19:30:02


Disclaimer: I'm not an MPL expert, but I think I get the gist of it.

Martijn van der Lee <martijn_at_[hidden]> writes:

> Hi,
>
>I've been following the discussion on a HelloWorld for the MPL
>framework with great interrest, in the hope of understanding what
this
>MPL thing really is, sadly enough, I am no further than I was a week

ago.

Don't worry, it took me a while to wrap my head around it, too. To
me, MPL is as tough or tougher than generic programming and the STL
was 5 years ago. It's a new perspective that we're not used to.

>Could anybody please explain what MPL is, what it does, why I should

>wish to use it, when I should use it and why it is better than the
>alternative solutions that may exist for the problems the MPL was
meant
>to solve?

Firstly, are you familiar with the concept of meta programming? In a
nutshell, meta programming is writing programs to create or modify
other programs (possibly recursively including other meta-programs).
At its very simplest, you could consider search and replace on source
files meta-programming. Breifly, consider native and external
meta-programming. Writing a Perl script to modify C++ source files
would be external. In C++, templates provide a native
meta-programming facility. The upshot of native facilities:
everybody can use them; the downside: native facilities can be
limiting. In the specific case of C++, it turns out that some very
clever (and rather non-obvious) use of templates can do some amazing
things. Spirit and Lambda are libraries that mask cool template
wizardry to make useful tools accessible. So, just like lambda makes
writing lambda functions more accessible, MPL makes writing meta
programs more accessible.

In a sense, "Why use MPL?" boils down to, "Why meta-program?" I'll
let the STL stand as an answer to that question. However, templates
provide a somewhat limited meta-programming model. Since C++ is here
to stay, we may as well make the most of what we have. MPL exploits
the same template mechanisms that made the STL possible and develops
a substantial compile time programming model. For actual examples,
refer to the documentation that Dave mentioned.

As to why you should use it: it is safer, more robust, more
effecient, more flexible, etc etc than anything you are likely to
write in a reasonable time. This is true of any good library. When
you should use it it depends on what you do. Writing generic,
reusable components is a good start. I expect that once I am
comfortable with it, though, I will start using it in places I
wouldn't anticipate now.

>Is there any problem for which MPL is the ideal (if not the only)
>solution and are there cases in which MPL is a clear winner over
>standard C++ code?

Like any library, use it when you like the abstractions it provides
and don't mind the design trade-offs.

>I'm sure you Boost guys have created as wonderful a tool with MPL as

>you have with some of your other libraries but at the moment it just

>seems like a really complicated way of doing things. If performance
is
>the only reason for choosing MPL than I doubt whether it would
>outweight the added development effort.

Is the STL written only for performance reasons? Did you fight tooth
and nail against iterators because they were a really complicated way
of doing things? Do you appreciate them now? Make it as simple as
possible, and no simpler. I think MPL scores very well here, because
the complexity it masks is mind-numbing. Without MPL or something
like it, mere mortals would never attempt the things it does.

Cheers-
Augustus

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com


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