Namespace: I like boost::container::multi_indexed_sets But I could live without
Powell, Gary <powellg <at> amazon.com> writes: Reply to the 2nd part of your post, here I go. the "::container".
multi_indexed_sets? did you mean indexed_sets or is this a new proposal for the namespace name?
I'm not crazy about lifting the namespace into boost. I foresee that boost is going to get cluttered so some organization early will help.
As I say in the review notes, I'll do whatever people agree on. My only concern with having the namespace as a sub of boost::container is that ids that long as boost::container::multi_index will favor using directives or namespace aliases. Anyway.
"mix" hits my pun loving funny bone, hence it shouldn't be used! Besides "mix_in" has a different meaning and will confuse people. I don't have to type the name of the container very often in comparison to everything else so a clear name is worth a few extra characters.
Yeah, I think you're right. mix dropped (seemed like I was the only one that liked it). We are left then with indexed_set, multicontainer, multi_container.
Regular indices: I like "ordered indices" as it says what they are. I hate writing documentation when readinghte code explains everything clearly.
Index names: ordered_unique ordered_non_unique They say what they do. Always good for self docuementing code.
"set_like" sounds so 90's teenage talk... "whatever.."
I like them too. Future hashed indices can be called unordered_unique and unordered_non_unique, in heavenly harmony with upcoming std hashed sets.
Nth_index_type & family. Yeah, I'd like to see the _type dropped. If you have to have a unique name, "_t" is ok, but still sucks.
The only places where dropping "_type" causes problems is iterator_type<> and const_iterator_type<>. But wait, I think I have something that may please everybody: template<int N> struct nth_index; template<typename Tag> struct index; template<int N> struct nth_index_iterator; template<int N> struct nth_index_const_iterator; template<typename Tag> struct index_iterator; template<typename Tag> struct index_const_iterator; Comments?
Header Organization: The only reason for omitting dependant headers is if they are not "dependent." I.e. that you need the sub header for accessing the container, but the primary header is all that is needed to declare the container. Otherwise include everything that is required. (IMO)
This seems to lead to a finer-grained separation. OK with me, monolithic headers do not seem to be on vogue at Boost. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo