From: =?iso-8859-1?Q?Joaqu=EDn=20M=AA=20L=F3pez=20Mu=F1oz?= <joaquin@tid.es>
Rob Stewart ha escrito:
From: "Thorsten Ottosen" <nesotto@cs.auc.dk>
typedef multi_indexed_container< employee, index::index_list<
^^^^^^^^^^
Why not just "index::list?"
"list" seems too terse to me. It could lead the reader to think it is some sort of container (which is not). Take into account the namespace can be populated in the future with other containers derived from the main one.
I suppose in a given use case, a "using boost::index" (or "using boost::multi_index") may be in force, so it would boil down to just "list." However, neither "index_list" nor "list" really says the right thing. How about turning it around: list_index?
index::ordered_unique<index::identity<employee> >, index::ordered_non_unique<index::member<employee,int,&employee:age> >, index::sequenced<>
employee_set;
Before I wasn't sure where member, identity etc came from.
It was the same namespace before, but I very much like your suggestion. The lingering question in my mind is whether your "index" namespace should be called "multi_index." That would tie the namespace to the class better and means that the library could be called Boost.MultiIndex without leading to confusion.
FWIW, I too prefer multi_index. boost::index seems way too generic a name for a library of multi-indexed containers (specially if we don't move inside boost::container.)
To sum it up, my 2nd proposal was:
namespace boost::multi_index, container boost::indexed_container
and Thorten's, with your proposed refinements, is
namespace boost::multi_index, container boost::multi_index_container
So it all boils down to choosing between indexed_container/multi_index_container. No strong opinions
I agree with Thorsten's proposal. "multi_index_container" is much clearer.
from my part here. There's still the pending issue of whether to move into boost::container.
I think the argument that "a" container library has to be the first one is valid, but was there sufficient consensus that such a namespace was warranted? If there is consensus, your library is a perfect candidate. If there isn't, it would be painful to put your library in the "container" namespace only to rip it out later. If you don't do it and folks agree it is worthwhile, then yours would be just one more library to move into the namespace at that time. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;