>Please find some preliminary documentation for multiindex_set >at: > >http://groups.yahoo.com/group/boost/files/multiindex.zip
Hi Joaquín,
I took a quick look at multiindex.html, and found it quite interesting. It appears to meet a common need. Here are some specific (but not carefully thought out) comments:
* The "multiindex_set" name seems awkward to me. Maybe "indexed_set" or "set_index"?
* 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;* The need for an update member function also comes up in other non-STL containers like B-trees, so don't worry that it is an add-on.
* 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 SmithAnyhow, I'm glad to see you working on this, and hope you will continue with it.
--Beman
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
