Hi, This is my 2nd proprosal for naming of the library formerly known as Boost.IndexedSet. I've changed my mind with respect to some of the decisions stated at my first proposal (rationale is given.) There is also a minor clashing issue that I'd want to publicize before the final commit. I list here only the points that have changed with respect to my first proposal, that you can find at: http://lists.boost.org/MailArchives/boost/msg62611.php If no one complains about this 2nd proposal I'll apply the necessary changes by the end of the following week. 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. CONTAINER NAME Proposal: indexed_container. Rationale: composite_container sounded too vague; indexed_container is reminiscent of the previous name indexed_set, so in a sense it won't break the (admittedly shallow) familiarity with the library that boosters might have built up so far. LIBRARY NAME: Proposal: Boost.MultiIndex. Rationale: In sync with the namespace. REST OF NAMING ISSUES: Like in the 1st proposal. NAME CLASHING ISSUE: The renaming of nth_index_type & familiy to nth_index etc. uncovered a name clashing issue in GCC (and only in this compiler AFAIK): using namespace boost::multiindex; typedef index<indexed_t,some_tag>::type index_t; //clash! The index<> class template clashes with the non-standard C-runtime function index() living in <string.h>. Unfortunately, most std headers (even C++ ones) seem to implicitly include <string.h> as well, so the clash is likely to occur. In my opinion, this clash is not important enough, for the following reason. index<...> is provided mainly as a workaround for MSVC 6.5, which has well-known problems with nested templates. In GCC one can write instead: using namespace boost::multiindex; typedef indexed_t::index<some_tag>::type index_t; using the nested index<...> variant. This is always preferrable, and does not clash in any manner with global index() in <string.h>. Of course, there are other obvious resolutions to this clashing issue. For this reason, my proposal is to effectively change index_type<...> to index<...>, and similarly with the other related template classes as previously proposed, even in the presence of this clashing issue. If someone thinks differently, please tell me so. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
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)? 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). -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com
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
participants (4)
-
Daryle Walker -
JOAQUIN LOPEZ MU?Z -
Joaquín Mª López Muñoz
-
Pavel Vozenilek