>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
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
