[boost] Re: tuple patch (constructing from a pair)

From: Joel de Guzman (joel_at_[hidden])
Date: 2005-02-14 23:13:33

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