Re: [boost] If boost::fusion is the hammer, then what's the nail?

From: Joel de Guzman (joel_at_[hidden])
Date: 2006-12-14 18:43:21

David Abrahams wrote:
> Weapon Liu <weapon.liu_at_[hidden]> 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