Disclaimer: I'm not an MPL expert, but I think I get the gist of it. Martijn van der Lee <[EMAIL PROTECTED]> 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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost