From: Joaquin M Lopez Munoz (joaquin_at_[hidden])
Date: 2004-03-26 14:15:02
Powell, Gary <powellg <at> amazon.com> writes:
Reply to the 2nd part of your post, here I go.
> I like boost::container::multi_indexed_sets But I could live without
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;
> 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
JoaquÃn M LÃ³pez MuÃ±oz
TelefÃ³nica, InvestigaciÃ³n y Desarrollo
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk