Re: [Boost-users] Multi Index: Nested std::pair

Subject: Re: [Boost-users] Multi Index: Nested std::pair
From: Etienne Philip Pretorius (icewolfhunter_at_[hidden])
Date: 2009-04-27 05:12:52

Igor R wrote:
>>                boost::multi_index::ordered_unique<
>>                    boost::multi_index::composite_key<
>>                        element_t,
>>                        boost::multi_index::member<
>>                            element_t,
>>                            unsigned char,
>>                            &element_t::x
>>                        >,
>>                        boost::multi_index::member<
>>                            element_t,
>>                            unsigned char,
>>                            &element_t::value
>>                        >
>>                    >
>>                >
>>
>> As it is not clear in the documentation what the
>> "boost::multi_index::ordered_unique" scope is.
> 
> The scope is the key you define under "ordered_unique". In the above
> example you define a unique key that consists of (x, value). I.e., the
> container would disallow duplicate (x, value) pair.
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users

Hello list,

You see I need all the values in the container, but I only perform 
operations on a subset based on the least amount of unique values per 
row or per column. The problem is, when I recode the algo to build up 
the relationship on every iteration and the destroy it when it goes out 
of scope and then update the contents of the container based on the 
selected column or row - causes too much computational overhead as I am 
testing every element in every row or column rather then only ones that 
should qualify (unique values per row or column).

The container builds up the relationships defined, when it is populated, 
and then adjusts it as modifications occur to the contents, allowing me 
not to have to worry about the book keeping of the relationships. It 
should also be faster as lifetime of the container holds the 
relationships relevant and are re-evaluated on change of the containers 
contents rather than build up and destroyed the relationship on every 
iteration.

Kind Regards,
Etienne