Hello Daryle, Daryle Walker ha escrito:
I'm trying out a multi-indexed container that uses a set-like (ordered_unique) interface and a vector-like (random_access) interface. Each interface has a "max_size" member function. Could they ever return different values?
No, they internally forward a common function owned by the multi_index_container class itself. Admittedly, this fact is not explicitly documented, although the standard requirements for max_size() (see 23.1/5) talk about "size() of the largest possible container", so implying that all indices of the same multi_index_container must return the same value for this function.
Some functions, like (member) swap and clear, have no definitions given. It seems like the author assumes that we'll assume that the undefined functions work like those in STL. But I'll prefer something more precise, to (1) confirm the exact semantics and (2) know the exact complexity these functions may have. (I noticed this problem while I was trying to define the complexity of my wrapper class's member functions.)
The idea is that the reference only documents functions whose semantics and complexity are not exactly covered by the requirements for the models each type of index satisfies. For instance, in the introduction of ordered indices reference (http://boost.org/libs/multi_index/doc/reference/ ord_indices.html#ord_indices ), it reads: "Except where noted, ordered indices (both unique and non-unique) are models of Sorted Associative Container and Unique Associative Container, much as std::sets are. Accordingly, validity of iterators and references to elements is preserved. We only provide descriptions of those types and operations that are either not present in the concepts modeled or do not exactly conform to the requirements for these types of containers." and similarly for the rest of index types. There are more member functions which are covered by this "default clause", for instance [r]begin() and [r]end(), as well as most nested typedefs (iterator, value_type, reference...)
Some member functions, like the aforementioned "max_size" and "clear," seem to be same for all index styles. Could those be re-factored into the main class, like "get_allocator" is? Or would that mess up the ability to keep each index's interface independent?
I'm not sure what you mean: if by refactoring you mean having them in the interface of multi_index_container class itself, you already have something equivalent, because a multi_index_container inherits the public interface of its first index. If what you propose is to remove those member functions from the index interfaces, I think this would gratuitously complicate things for the user: she wouldn't be able, for instance, to clear an index if given the index interface alone. Also, dropping these functions would render indices less similar to the containers they aim to model as closely as possible. Thank you for using Boost.MultiIndex, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo