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:
> > NAMESPACE
> > * 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 acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk