"JOAQUIN LOPEZ MU?Z" <joaquin@tid.es> wrote in message news:1d3feb1d1868.1d18681d3feb@tid.es...
I would try first to forge the Index concept. Then a Composite Container is more or less trivially defined as a "composition" (wants definition) of indices. We could call an Associative Composite Container to a Composite Container whose indices model Associative Index (wants def). A bimap is a model Assoc Comp Container, as well as some instantiations of indexed_set.
That sounds like a good approach. However, it looks like you've already defined ordered indices as Sorted Associative Containers and Unique Associative Containers. So really, you only need to formalize the refinements that make them Indices, rather than SACs or UACs.
The part of index retrieval (the get<> stuff) I don't see any hope of being conceptualized, as bimap, for instance, could perfectly lack such interface in favor of something simpler for the data structure at hand.
Well, that would be a refinement only specified for composite_container. Composite Container need not specify how the indices are accessed.
Probably, a Composite Container is *not* any kind of Container (its indices are, though): imagine an indexed_set that does not inherit the functionality of its first index.
Well, that's an interesting statement. I guess now that you mention it, a Composite Container is really a Composite Index or an Index Collection.
[...] Well, I'll try to come up with something, but it'll take long. If this is a requirement for acceptance, it certainly will affect to the availability time. [...]
No, my vote is not contingent upon a concept description. Dave --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.581 / Virus Database: 368 - Release Date: 2/9/2004