开发者

What's the point of boost::multi_index_container::index<Tag>::type?

开发者 https://www.devze.com 2023-01-13 19:36 出处:网络
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

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 ch开发者_运维问答oose 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.

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号