Larry Evans wrote:
On 02/14/2005 07:38 PM, Joel de Guzman wrote:
Larry Evans wrote:
[snip]
Could you give more details so I can find it?
I just posted it. You should see it by now. If not:
I see it.
Here's what I am planning:
1) I intend to refactor fusion to allow different forms of containers with varying characteristics. I plan to have: a) vector b) list c) set d) map
[snip]
4) As I intend to follow the MPL mold, I will follow MPL naming convention (e.g. "at" instead of "get", vector instead of tuple).
I'm confused because an instance of mpl::vector<T1,T2,...,Tn> contains no data but an instance of a tuple<T1,T2,...,Tn> contains an instance of T1,T2,...,Tn. Aren't both needed?
fusion::vector, fusion::list, fusion::set and fusion::map all have data. These are different incarnations of the tuple with different characteristics. So, like STL and MPL, you can choose the right structure for your needs. The unifying factor is fusion's *iterator* concept. For instance, while developing Spirit-2, I came across the need to have a cons-list based hetero-structure which is cheaper to build piece meal than a vector (flat) based structure that Fusion currently uses. Later on, I came across the need to have an associative tuple. So, really, it should be the same as STL. While stl::vector, stl::list, stl::set and stl::map are homo-structures, fusion::vector, fusion::list, fusion::set and fusion::map are hetero-structures. All Fusion algorithms can work on the various forms. And, any structure that conforms to Fusion's iterator concept automatically becomes a full fledged citizen. std::pair comes to mind. Cheers, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net