An advantage other languages such as Python and Lisp/ Scheme, ML and Haskell,
etc., over C++ is the ability to have heterogeneous containers that can hold
arbitrary element types. All the containers in the standard library can only
hold a specific type. A
can only hold
only hold elements of type
and so on.
True, you can use inheritance to make the containers hold different types,
related through subclassing. However, you have to hold the objects through
a pointer or smart reference of some sort. Doing this, you'll have to rely
on virtual functions to provide polymorphic behavior since the actual type
is erased as soon as you store a pointer to a derived class to a pointer to
its base. The held objects must be related: you cannot hold objects of unrelated
types such as
etc. Oh sure you can use something like Boost.Any
to hold arbitrary types, but then you pay more in terms of runtime costs and
due to the fact that you practically erased all type information, you'll have
to perform dangerous casts to get back the original type.
library written by Jaakko
Jarvi provides heterogeneous containers in C++. The
is a basic data structure that can hold heterogeneous types. It's a good first
step, but it's not complete. What's missing are the algorithms. It's nice that
we can store and retrieve data to and from tuples, pass them around as arguments
and return types. As it is, the Boost.Tuple
facility is already very useful. Yet, as soon as you use it more often, usage
patterns emerge. Eventually, you collect these patterns into algorithm libraries.
Hmmm, kinda reminds us of STL right? Right! Can you imagine how it would be like if you used STL without the algorithms? Everyone will have to reinvent their own algorithm wheels.
Fusion is a library and a framework similar to both STL and the boost MPL. The structure is modeled after MPL, which is modeled after STL. It is named "fusion" because the library is reminiscent of the "fusion" of compile time meta-programming with runtime programming. The library inherently has some interesting flavors and characteristics of both MPL and STL. It lives in the twilight zone between compile time meta-programming and run time programming. STL containers work on values. MPL containers work on types. Fusion containers work on both types and values.
Unlike MPL, Fusion
algorithms are lazy and non sequence-type preserving. What does that mean?
It means that when you operate on a sequence through a Fusion algorithm that
returns a sequence, the sequence returned may not be of the same class as the
original. This is by design. Runtime efficiency is given a high priority. Like
MPL, and unlike
fusion algorithms are functional in nature such that algorithms are non mutating
(no side effects). However, due to the high cost of returning full sequences
such as vectors and lists, Views are returned from Fusion
algorithms instead. For example, the
transform algorithm does not actually
return a transformed version of the original sequence.
transform returns a
transform_view. This view holds a
reference to the original sequence plus the transform function. Iteration over
will apply the transform function over the sequence elements on demand. This
lazy evaluation scheme allows us to chain as many algorithms
as we want without incurring a high runtime penalty.
The lazy evaluation scheme where algorithms return views
allows operations such as
push_back to be totally generic. In
push_back is actually a generic algorithm
that works on all sequences. Given an input sequence
and a value
push_back algorithm simply returns
a view that holds a reference to the original sequence
and the value
that were once sequence specific and need to be implemented N times over N
different sequences are now implemented only once.
Fusion provides full round compatibility with MPL. Fusion sequences are fully conforming MPL sequences and MPL sequences are fully compatible with Fusion. You can work with Fusion sequences on MPL if you wish to work solely on types . In MPL, Fusion sequences follow MPL's sequence-type preserving semantics (i.e. algorithms preserve the original sequence type. e.g. transforming a vector returns a vector). You can also convert from an MPL sequence to a Fusion sequence. For example, there are times when it is convenient to work solely on MPL using pure MPL sequences, then, convert them to Fusion sequences as a final step before actual instantiation of real runtime objects with data. You have the best of both worlds.