Daryle Walker ha escrito:
On 4/10/04 5:13 PM, "JOAQUIN LOPEZ MU?Z" <joaquin@tid.es> wrote:
[SNIP]
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. [TRUNCATE]
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) ordered_unique, ordered_non_unique, sequenced, index_list, tag, index nth_index, etc. (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