Re: [boost] Re: Interest in multiindex_set?(again)

From: JOAQUIN LOPEZ MU?Z (joaquin_at_[hidden])
Date: 2003-07-07 17:25:00

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