Boost.MultiIndex iterator types
I have two multi_index_containers that are identical except for the ordering of the iterators. For example: struct Foo { long x, y; }; typedef boost::multi_index_container<Foo, indexed_by<ordered_non_unique<composite_key<Foo, member<Foo, long, &Foo::x>, member<Foo, long, &Foo::y> > > > > FooAscending; typedef boost::multi_index_container<Foo, indexed_by<ordered_non_unique<composite_key<Foo, member<Foo, long, &Foo::x>, member<Foo, long, &Foo::y> >, composite_key_compare<std::greater<long>, std::greater<long> > > > > FooDescending; The containers are indexed on composite keys of x and y - one in ascending order of y, the other in descending order. I have code that operates on iterators over these containers. Conveniently, the operation is identical, save for the ordering, so I can reuse the interesting code that works on these iterators. However, I am finding that the iterator types for the two containers are identical. Yet if I just define my overload for one of the iterators, everything works as expected. So my question is, is there a way to specify a generic iterator over a multi_index_container such that code on iterators can be reused in this way? It seems from the symbols gcc spits out that the iterator type depends only on the type held and the number of indices in the container (i.e. a container with a unique key on just Foo::x would also have its iterator type collide with FooAscending::iterator and FooDescending::iterator). Thanks, Jonathan
Hi Jonathan, ----- Mensaje original ----- De: Jonathan Wang <jtwang@bitdrip.net> Fecha: Sábado, Febrero 3, 2007 5:10 am Asunto: [Boost-users] Boost.MultiIndex iterator types Para: boost-users@lists.boost.org
I have two multi_index_containers that are identical except for the ordering of the iterators. For example:
struct Foo { long x, y; }; typedef boost::multi_index_container<Foo, indexed_by<ordered_non_unique<composite_key<Foo, member<Foo, long, &Foo::x>, member<Foo, long, &Foo::y> > > > > FooAscending;
typedef boost::multi_index_container<Foo, indexed_by<ordered_non_unique<composite_key<Foo, member<Foo, long, &Foo::x>, member<Foo, long, &Foo::y> >,
composite_key_compare<std::greater<long>, std::greater<long> > > > > FooDescending;
The containers are indexed on composite keys of x and y - one in ascending order of y, the other in descending order.
I have code that operates on iterators over these containers. Conveniently, the operation is identical, save for the ordering, so I can reuse the interesting code that works on these iterators. However,I am finding that the iterator types for the two containers are identical.
Yes they are in this particular case. More genrally, the type of the iterators of multi_index_containers depends on 1. The element type, 2. the kind of index (ordered, hashed, sequenced, random access), 3. the kind of indices declared after the associated index; But this fact is *NOT* documented and therefore you shouldn't rely on it --for instance, the situation changes entirely when safe mode is activated. There is no guarantee that this condition won't change in future releases of the lib.
Yet if I just define my overload for one of the iterators, everything works as expected.
Correct, as both iterator types are the same.
So my question is, is there a way to specify a generic iterator over a multi_index_container such that code on iterators can be reused in this way? It seems from the symbols gcc spits out that the iterator type depends only on the type held and the number of indices in the container (i.e. a container with a unique key on just Foo::x would also have its iterator type collide with FooAscending::iterator and FooDescending::iterator).
It's not exactly like you say, the conditions for iterator type equality are described above. But then again, this is not a documented or stable guarantee, so if you need to write code that will work for any iterator of a multi_index_container your best option is to templatize the code on the iterator type. Hope this helps, please come back if anything's not clear. Thank you for using Boost.MultiIndex, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
participants (2)
-
"JOAQUIN LOPEZ MU?Z"
-
Jonathan Wang