If you have a boost::multi_index_container< >
with multiple indices, there are obviously multiple ways to iterate over it - each index defines a way. For instance, if you have an index with tag T
, you can iterate from container.get<T>().begin()
to container.get<T>().end()
.
If you try to do so in a for-loop (and do not have C++0x auto
), the type of the iterator is multi_index_container<...>::index<T>::type::iterator
. Now index<T>::type
will be boost::multi_index::detail::ordered_index or something structurally equivalent. E.g. it will provide an iterator
typedef, and a begin()
method.
Now my question is, since multi_index_container< >::index<T>
seems to exist only to typedef index<T>::type
, and index<T>::type
has known members, why doesn't index<T>
typedef those members ? This would allow you to write multi_index_container<...>::index<T>::iterator
.
Similarly, why is multi_index_container< >::index_iterator<T>
not an iterator? multi_index_container< >::index_iterator<T>::type
is, but why did Boost choose an embedded typedef ? Again the ::type
seems to add only clutter.
Personally, I think it was just an oversight. Especially with such a non-trivial library such as boost::multi_index_container<T>
. I often find code I've written that aren't bugs per se, but felt that I could've been done better in retrospect.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With