Boost logo

Boost :

From: Joaquín Mª López Muñoz (joaquin_at_[hidden])
Date: 2004-04-12 01:14:28

Daryle Walker ha escrito:

> On 4/10/04 5:13 PM, "JOAQUIN LOPEZ MU?Z" <joaquin_at_[hidden]> wrote:
> [SNIP]
> > * Proposal: boost::multi_index. This differs from
> > the previous proposal in which boost::container is
> > not used; rationale: resulting qualified ids would
> > be too long, which would force most users to use
> > namespace aliases (not a good thing, this has been
> > discused before in connection with Boost.Filesystem)
> > or apply using directives. Another reason is that a
> > good deal of preexisting Boost containers don't live
> > in boost::container and it does not seem such a
> > migration will ever take place.
> But a lot of containers were made before the initiative for sub-namespaces.
> Some library has to volunteer to be the first of a new namespace. Also,
> isn't "multi_index" longer than "container" (unless you were going to add an
> inner sub-namespace, which probably would be too much)?

The problem is that, regardless of whether the container is subsumed
into boost::container or not, it needs a namespace of its own, for the
several utility classes coming with the main class, like (to name a few)


(there might be a couple of dozens or so of them, haven't counted them up.)
So, if we agree that we need a multi_index namespace the question can be
formulated as: should we use boost::multi_index or boost::container::multi_index?
My proposal for the former aims to keep qualified names reasonably short.

> Would any other
> type besides your current ones ever qualify to go into a "multi_index"
> namespace? We should limit the number of exclusive namespaces (unless the
> library is ridiculously huge, like Regex or Spirit).

The idea is that some types derived from the main container class
will be living into multi_index in the future. The first targeted
derived container is the infamous bidirectional map or bimap.

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo

Boost list run by bdawes at, gregod at, cpdaniel at, john at