Re: [boost] [tuple] any interest in a unique_tuple<...>?

Subject: Re: [boost] [tuple] any interest in a unique_tuple<...>?
From: Hui Li (hui.li_at_[hidden])
Date: 2014-03-08 15:00:00

On Mar 8, 2014, at 12:41 PM, Steven Watanabe <watanabesj_at_[hidden]> wrote:

> AMDG
> 
> On 03/08/2014 09:24 AM, Hui Li wrote:
>> Testing the water, see if anyone might find this useful.
>> Any comments/suggestions are absolutely welcome and appreciated!
>> 
> 
> The behavior of this seems a bit odd to me.
> If I needed something like this, I think
> I would prefer to create a normal tuple or
> fusion::set in conjunction some form of
> set_union algorithm.

That certainly would achieve similar functionality. But I do find that simply putting two "set"s inside
another "set" to achieve "set union" is convenient. Also the fact that std::tuple and fusion::set care about
the order in which the element types are specified can cause trouble, or at least make certain things hard
(sometimes may not even be possible), i.e., when it comes to constructors,  element-wise comparison and swap etc.

> 
>> unique_tuple<T...>, where types in <T...> may themselves be other unqiue_tupe<...>'s,
>> contains exactly one copy of each of the "finally nested" element types in <T...>,
>> regardless of how many times a type appears in the type parameter pack,
>> or how deeply it is nested inside one or more unique_tuple's in <T...>.
>> 
>> unique_tuple<T...> differs from std::tuple<T...> and boost::fusion::set<T...> etc in that nested unique_tuple's
>> are effectively "flattened", and elements contained are unique no matter how complex the nesting
>> gets, or how many times or how deeply nested the element type is in <T...>.
>> 
> 
> In Christ,
> Steven Watanabe
> 
> 
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost