Si vous avez un boost::multi_index_container< > avec plusieurs index, il y a évidemment plusieurs façons de parcourir: chaque index définit un chemin. Par exemple, si vous avez un index avec l'étiquette T, vous pouvez itérer de container.get<T>().begin() à container.get<T>().end(). Si vous essayez de le faire dans une boucle for (et que vous n'avez pas C++ 0x auto), le type de l'itérateur est multi_index_container<...>::index<T>::type::iterator. Maintenant index<T>::type sera boost :: multi_index :: detail :: ordered_index ou quelque chose de structurellement équivalent. Par exemple. il fournira un typedef iterator et une méthode begin().Quel est le point de boost :: multi_index_container :: index <Tag> :: type?
Maintenant, ma question est, puisque multi_index_container< >::index<T> ne semble exister que pour typedef index<T>::type et index<T>::type a des membres connus, pourquoi ne index<T> typedef ces membres? Cela vous permettrait d'écrire multi_index_container<...>::index<T>::iterator.
De même, pourquoi multi_index_container< >::index_iterator<T> n'est-il pas un itérateur? multi_index_container< >::index_iterator<T>::type est, mais pourquoi Boost a-t-il choisi un typedef incorporé? Encore une fois le ::type semble ajouter seulement le fouillis.
J'ai dû chercher ça dans notre code parce que je ne connaissais pas le type ::. Il semble que nous les ayons tous typés, de sorte qu'ils n'apparaissent pas dans la mise en œuvre. Donc pas de réponse de ma part: je n'ai jamais eu de problème avec ça donc je n'ai jamais pris la peine de comprendre pourquoi ... – stefaanv