On 8/10/06, John Maddock <john@johnmaddock.co.uk> wrote:
"The core of bimap will be obviously a multi_index_container. The basic idea to confront the implementation of the bimap class is to use iterator_adaptor to convert the iterators from Boost.MultiIndex to the std::map and std::set behaviour. The map_view and the set_view can be implemented directly using this new transformed iterators and a wrapper around each index of the core container. However, there is a hidden idiom here, that once coded will be very useful for other parts of this library and Boost.MRU library. Following the ideas from iterator_adaptor, Boost.Bimap views are implemented using a container_adaptor. Basically there are several template classes (for example map_adaptor and set_adaptor) that takes a std::map signature conformant class and new iterators, and adapts the container so it now use this iterators instead of the original ones. For example, if you have a std::set<int*> you can build other container that behaves exactly as a std::set<int> using set_adaptor and iterator_adaptor. The use of this two tools together is very powerful. A container_adaptor can take classes that do not fulfill all the requirements of the adapted container. The new container must define these missing functions."
Sounds interesting, and might well be useful in it's own right, but I would place Bimap and a MRU cache higher up my wish list.
Yes, I will start Boost.MRU as soon as we settled down Boost.Bimap and it queued in the formal review process. The thing is that I will surely use ContainerAdaptor for Boost.MRU. After that, if it successfully applied in two libs (and if I can implement PointerContainter using it as Joaquin suggested) i can extract the Boost.ContainerAdaptor and make some docs about it. Regards Matias