David Abrahams wrote:
Weapon Liu <weapon.liu@gmail.com> writes:
I think this is the right place to ask this question. As cool as boost::fusion is, there's still one question that bothers me, that is, if boost::fusion is the hammer, then what's the nail?
I sure know that it's generic( more so than boost::tuple) and it's complete( with a bundle of algorithms and cool utilities), and it seems that it "solves" some problem quite well( when I read the documents).
However, I found it bothering that the documents didn't even mention one real-world application( boost libs aside).
Well, by nature the uses for static metaprogramming systems tend to be in writing libraries. Generally speaking, programs that process the types and values in a tuple (that's what Fusion is for), allow us to build interfaces that are user-configurable to work with any collection of heterogeneous types.
One good example is http://boost.org/libs/iterator/zip_iterator.html. If you only ever had to zip together three specific sequence types (e.g. an array of longs, a vector of doubles, and array of strings), there might not be much point in using something like fusion. However, once you realize you also need to zip together the elements of three lists, or five sequences, you don't want to have to repeat yourself. You write a template to handle it, and now you have a library.
Why you'd want a zip_iterator is covered somewhat at the link above, but a simple answer is to consider the std::transform algorithm, which has overload that take one or two input sequences. What if you want to transform three, four, or five input sequences? How many overloads do we need?
You can compare a version of zip_iterator that uses fusion (zip_iterator_fusion) with one that just uses boost::tuple (HEAD) at http://tinyurl.com/y9ax7t
I've also used tuples to do high-performance computations on groups of matrices that may have different shapes and layouts encoded in their types (think of just doing matrix addition for a simple example). If you don't want to rewrite the code every time you reconfigure the set of matrices you're working with, you need a heterogeneous collection that you can traverse programmatically.
Another potential use would be in generalizing GIL's color-spaces. If you have N such things and M functions for each, you'll have to implement NxM functions. Generic programming will narrow that to just M algorithms for all N color-spaces. If you have this kind of repetitious programming, fusion should be your friend. Inspection of GIL code reveals that, in many cases, you can even simply reuse the fusion algorithms, or use it as building blocks, much like STL algos. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net