Re: [Boost-users] [multi-index] No constructor that takes allocator only

----- Mensaje original ----- De: Michael Fawcett Fecha: Miércoles, Enero 30, 2008 9:23 pm Asunto: Re: [Boost-users] [multi-index] No constructor that takes allocator only Para: boost-users@lists.boost.org

On Jan 30, 2008 3:06 PM, Joaquin M Lopez Munoz wrote:

...

I'm holding your proposal in my todo list, but I have to think it over a bit.

I trust you'll come to the best decision. Really it comes down to what customization point is more often used (since the interface will favor that), and that is invariably the compare parameter. My original suggestion should probably be ignored in favor of keeping with the set interface.

It's possible that both ctors could be provided, because the situation for multi_index_container is not entirely equivalent to that of std::set. I'll keep you informed.

As an aside, does Boost.MultiIndex model any existing Boost concepts (e.g. AssociativeContainer)?

http://www.boost.org/libs/concept_check/ reference.htm#container-concepts I found some documentation here ( http://www.boost.org/libs/multi_index/doc/tutorial/ techniques.html#emulate_std_containers ) , that hints it might, but no explicit mention of modeling Concepts.

Well, the answer is, in general, no. multi_index_containers certainly model Container, but nothing beyond that (Sequence or AssociativeContainer) for a variety of possible reasons: * Index #0 (as you know, multi_index_containers inherit the public interface of that index) might have some slight deviations from the interface of the corresponding container: for instance, sequenced indices are like std::lists, but push_back() and other memfuns have a different signature. * Elements are immutable (unlike standard Sequences). * Insertion semantics depends on every and each index comprising the multi_index_container, not only index #0. * Same for operation complexities: insertion, erasure, etc. So, you can get close to modelling a given Concept, but not strictly there. About the only exact match you've got is the emulation of std::set described at the section you refer to above. HTH, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo