Hi Beman,
----- Mensaje Original -----
[...]
> * The "multiindex_set" name seems awkward to me. Maybe
> "indexed_set" or
> "set_index"?
I don't like the name either, and would be happy if someone comes
with something better. Nevertheless, I don't think indexed_set is a
good choice: when picking up a name another one must be chosen
for the associated namespace (and it is convenient that these two are
not the same, for reasons explained vg in Boost.Tuple docs). I
chose multiindex_set/multiindex. The analogous indexed_set/index
does not fit: index is too broad a denomination for the namespace.
A related question: Should boost::multiindex::multiindex_set be
raised into Boost namespace as boost::multiindex_set (or whatever
its final name)? Seems the standard practice, but I think it is safer
to ask first.
>
> * It seems safer to me for the default to be indexes that are unique.
>
> * Separating the specification of uniqueness from the list of
> indices
> seems like a recipe for mistakes, particularly during maintenance.
> Is it
> possible to combine uniqueness specification with the index tuple?
> Perhaps
> your example could look like this:
>
> typedef boost::multiindex::multiindex_set<
> employee,
> boost::tuple< employee::comp_id,
> multi< employee::comp_name >,
> employee_name::comp_ssnumber >,
> > employee_set;
>
> or this:
>
> typedef boost::multiindex::multiindex_set<
> employee,
> boost::tuple< unique< employee::comp_id >,
> non_unique< employee::comp_name >,
> unique< employee_name::comp_ssnumber > >,
> > employee_set;
>
This is definitely a good idea, Fernando also hinted at symplifing
the specification of unique/non-unique indices. Any suggestion on how
to implement it? With two templates for unique and non-unique indices
the thing is simple; it is not as simple when only one class is marked.
Suggestions here are most welcome.
[...]
> * It isn't clear (or I missed it) if iterators are always
> logically
> const-iterators or not. In other words, could your example have
> been
> written like this?
>
> typedef index_type<employee_set,1>::type employee_set_by_name;
> employee_set_by_name& i=es.get<1>();
>
> employee_set_by_name::iterator it=i.find("Anna Jones");
> it->name="Anna Smith"; //she just got married to Calvin Smith
>
No it couldn't. Iterators and const_iterators (which incidentally are the
same) behave logically as const-iterators, just the same as in STL sets.
update() has been carefully crafted so that strong exception-safety is
provided: for that, it is necessary that a copy of the element is provided
instead of allowing some sort of in-place modification of the element.
This is discussed in some detail with Fernando somewhere up this thread.
> Anyhow, I'm glad to see you working on this, and hope you will
> continue
> with it.
>
Thanks for your interest. If no objection is raised I plan to submit
the library for pre-formal review in a couple of weeks.
Regards,
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
