Re: What is a==b supposed to do for two hash_sets?

[Joe Buck <Joe dot Buck at synopsys dot COM>]

On Tue, Feb 01, 2005 at 01:22:42PM -0800, Matt Austern wrote:
> Strictly speaking, what hash_set should do to conform to the container 
> requirements is to define x == y as x.size() == y.size() && std::equal 
> (x.begin(), x.end(), y.begin()).  This would give it different behavior 
> than what hash_set currently does, but probably no more useful.

Only *probably* no more useful?  Yes, there's a consistency argument for such
a definition, but no user would want such a definition, and would be quite
surprised by it.  A certain Emerson quote comes to mind, it seems like
foolish consistency.  A hash_set is a set, after all, and set equality is
defined as two sets having the same members.

Such a requirement for the equality function makes sense for a sequence or
an ordered associative container, but not for an unordered container.

> Just 
> leaving operator== out for unordered associative containers was 
> probably the right decision for TR1.

Well, it certainly would be better to leave out operator== than to
implement such a terrible definition as std::equal(x.begin(), x.end(),
y.begin()).  It might be better to use an explicit name making clear
that set equality is intended.

template<...>
class hash_set {
....
   template <typename ForwardIter>
   bool set_equal(ForwardIter first, ForwardIter last) const {
      if (std::distance(first, last) != size())
         return false;
      for (ForwardIter p = first; p != last; ++p) {
         if (find(*p) == end())
	    return false;
      }
      return true;
   }
   ...
};

inline set_equal(const hash_set<...>& a, const hash_set<...>& b) {
   return a.set_equal(b.begin(), b.end());
}