[boost] [indexed_set] revised naming proposal

From: JOAQUIN LOPEZ MU?Z (joaquin_at_[hidden])
Date: 2004-04-10 16:13:49

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