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.