Re: [boost] [Multi-index] questions on max_size, incomplete docs, and common code

From: Joaquín Mª López Muñoz (joaquin_at_[hidden])
Date: 2007-08-02 10:06:15

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