From: David B. Held (dheld_at_[hidden])
Date: 2004-03-30 03:30:48
"JOAQUIN LOPEZ MU?Z" <joaquin_at_[hidden]> wrote in message
> 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.
--- 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk