Hi, On Tue, Mar 30, 2004 at 07:09:41PM +0200, Joaqu?n M? L?pez Mu?oz wrote:
NAMESPACE * 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 follow. Regards, Pavol