RE: [boost] Re: Formal Review: Indexed Set

I think there may be the problem that the various predicates used for the indices do not generally define comparison operators which compare predicates specialized on different types.
I think Gary and you are talking about different things. As you point out, there are difficulties in using the internal comparison objects of indices for defining operator <. Moreover, the standard clearly dictates that comparison between containers a and b be implemented as
lexicographical_compare(a.begin(),a.end(),b.begin(),b.end())
leaving no option to use other comparison predicate than operator < between element objects (see std 23.1.5) A rationale for the decision of not using the internal comparison predicates is given in
http://www.sgi.com/tech/stl/FAQ.html (section "Why doesn't map's operator< use the map's comparison function?")
So, IMHO there's little doubt that operator < between indices of an indexed_set must use value_type::operator <, conterintuitive as it may seem. A similar reasoning applies to equality comparison between indices.
Now, what Gary proposes (if I understand it right) is that we extend operator == and < so that indices on different element types can be compared. As I see it, this can be legally done, and it should do no harm as it merely extends the current functionality. It'd be something along these lines:
template<...(1),...(2)> bool operator==( const *index class*<...(1)>& x, const *index class*<...(2)>& y) { return x.size()==y.size()&&std::equal(x.begin(),x.end(),y.begin()); }
template<...> bool operator<( const *index class*<...(1)>& x, const *index class*<...(2)>& y) { return std::lexicographical_compare(x.begin(),x.end(),y.begin(),y.end()); }
where ...(1) and ...(2) are (possibly different) sets of template intantiation arguments for *index class*. Is this what's being proposed?
Right! Sorry I was too terse in my previous email. There is no reason why not to extend operator==() and operator<() to allow for two different container types to be compared. Either there is a comparison that will work for the two types or there is not, but it isn't the indexed set that enforces it, but rather std::equal and std::lexigraphical_compare. So the proprosal is to also extend all of the comparison operators to take the two complete sets of templated arguments. ie. Old: template<typename Value,typename IndexSpecifierList,typename Allocator> bool operator==( const indexed_set<Value,IndexSpecifierList,Allocator>& x, const indexed_set<Value,IndexSpecifierList,Allocator>& y); New: template<typename Value1,typename IndexSpecifierList1,typename Allocator1> template<typename Value2,typename IndexSpecifierList2,typename Allocator2> bool operator==( const indexed_set<Value1,IndexSpecifierList1,Allocator1>& x, const indexed_set<Value2,IndexSpecifierList2,Allocator2>& y); etc.. AFAIK there is no penalty for the library and much to be gained for the user. Yours, -Gary-

So the proprosal is to also extend all of the comparison operators to take
"Powell, Gary" <powellg@amazon.com> wrote the
two complete sets of templated arguments.
[snip]
etc.. AFAIK there is no penalty for the library and much to be gained for the
user.
Since this feature woud be applicable to indexed_set, circular_buffer, optional, standard containers - maybe it should be discussed separately from this library context, here or on comp.std.c++. If found useful it may be than applied Boost-wide. /Pavel

Powell, Gary <powellg <at> amazon.com> writes: [...]
New: template<typename Value1,typename IndexSpecifierList1,typename Allocator1> template<typename Value2,typename IndexSpecifierList2,typename Allocator2> bool operator==( const indexed_set<Value1,IndexSpecifierList1,Allocator1>& x, const indexed_set<Value2,IndexSpecifierList2,Allocator2>& y);
etc.. AFAIK there is no penalty for the library and much to be gained for the user.
Yes, I think there's no problem at all in implementing this extension. Consider it done (if I run into trouble I'll let you know.) Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

Hello Joaquín,
Yes, I think there's no problem at all in implementing this extension. Consider it done (if I run into trouble I'll let you know.)
Maybe the feature should wait a bit. I know to sound conservative but: - I know no container library with this feature - it does something at very core level It may be better to discuss it before adding. I personally do not see anything bad with it but I'm not labguage lawyer. /Pavel

Pavel Vozenilek <pavel_vozenilek <at> hotmail.com> writes:
Hello Joaquín,
Yes, I think there's no problem at all in implementing this extension. Consider it done (if I run into trouble I'll let you know.)
Maybe the feature should wait a bit.
I know to sound conservative but: - I know no container library with this feature - it does something at very core level
It may be better to discuss it before adding.
I personally do not see anything bad with it but I'm not labguage lawyer.
I'll happily do whatever the people agree on. Personally, I dont't see any core problem in the extension. The main reason I deem the change harmless is because we are replacing one function with one function: if we had to provide different overloads for say operator==, function template ordering would play a role, which is more dangerous (some compilers do not support this right.) My conclusion is then that the change cannot posibly break anything --but as I said before, I'll abide the mailing list's verdict. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
participants (3)
-
Joaquin M Lopez Munoz
-
Pavel Vozenilek
-
Powell, Gary