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

From: Beman Dawes (bdawes_at_[hidden])
Date: 2003-07-08 07:09:44

At 06:25 PM 7/7/2003, =?windows-1252?Q?JOAQUIN_LOPEZ_MU=3FZ?= wrote:

 >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.

I'm more interested in the class name than the namespace name. One problem 
at a time. If you weren't worrying about the namespace name, would you then 
like indexed_set as the class name? What are some other alternatives?

 >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.

Yes, I think so. It is a bit of a judgement call, but since the library is 
a very general purpose tool, and assuming the library only adds a few names 
to the namespace it lives in, I'd rather see it in namespace boost. Others 
may disagree; a lot of people like tall and deep namespace hierarchies even 
when the components are very general purpose.

 >>   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.

I don't see any acceptable (non-invasive) way to implement marking only one 
class. But the unique/non_unique two template approach seems perfectly 
acceptable. You could even argue that it forces the user to consciously 
make  the critical unique/non_unique decision for each index, so may reduce 
user error.

 >[...]
 >> * 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.

I understand the rationale for that, but am still concerned. There are many 
applications where the cost of a copy to apply a minor update is 
prohibitive. The user is then forced to add a layer of indirection, or use 
a home-made container. Ugh. This is one of the few cases I run into where a 
safe design is so inefficient compared to a traditional unsafe design that 
in real production code I might be forced to use the unsafe design. That 
makes me uncomfortable.

 >Thanks for your interest. If no objection is raised I plan to submit
 >the library for pre-formal review in a couple of weeks.

Good!

--Beman