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:
>----- Mensaje Original -----
>> * The "multiindex_set" name seems awkward to me. Maybe
>> "indexed_set" or
>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<
>> 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
>> * It isn't clear (or I missed it) if iterators are always
>> const-iterators or not. In other words, could your example have
>> 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
>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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk