From: Pavol Droba (droba_at_[hidden])
Date: 2004-03-30 14:16:22
On Tue, Mar 30, 2004 at 07:09:41PM +0200, Joaqu?n M? L?pez Mu?oz wrote:
> * Proposal: boost::container::multi_index
> * Rationale: The name suggests what the library is about and
> does not clash with the name of the container. Preferred
> to multiindex as English seems to like the former better.
> In favor of multi_index: Rob, Pavel (underscore-less variant),
> Arkadiy (for the container instead), Jeff, Thorsten, Paul, Matthew
> (only if pushed into boost::container).
> Alternatives: non-descriptive name (Tom), multi_indexed_containers.
> * Why inside boost::container? Seems like there's a general
> move to 2nd level namespaces, and this in particular
> saves us from repeating "container" in the library namespace
> itself. If anything, being the only library inside boost::container
> does not hurt. I've scanned the posts and these are the reviewers'
> opinions about this subject matter:
> In favor of pushing into boost::container: Matthew, Joerg
> Against: Dave
> Not sure: Jeff
> Don't care: Gary, Darren
I have just one remark about the namespace usage. IMHO it is an overkill to
provide a special namespace for every container.
I think, that putting this all containers into boost::container namespace
is verbose enough.
There has been very similar discussion about the algorithm namespace
(namely the string algorithm library). Current situation is that everything
resides in boost::algorithm namespace and interface names are lifted to boost
namespace. This model has been settled as a reasonable compromise.
It is worth to mention, that there are generaty more free stading names in algorithm
libraries than in the container ones. So if the name-clashing problem is not here,
I don't see it in container case.
Last argument in favor of proposal I have mentioned is to have one uniform setup
in the boost if possible. If the algorithm part is already settled, containers should
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk