From: Daniel James (daniel_james_at_[hidden])
Date: 2007-12-11 15:24:06
Hervé Brönnimann wrote:
> As for the equality comparison vs predicate, the same again is true
> for operator== for the standard associative containers, defined as
> a.size() == b.size() && std::equal(a.begin(), a.end(), b.begin()
> [sic] (no, *I* didn't forget the final paren, it's not on page 671
> either). Nowhere in that makes use of the "equivalence" implied by
> operator<, which is used for uniqueness in set/map and equivalence in
> multiset/multimap. So by defining equality in terms of the equality
> predicate for keys in order to check for the uniqueness property, but
> operator== for both keys and values in the implementation of
> operator== for unordered_map/multimap, you wouldn't exactly break new
> ground.
>
That's a very compelling argument. When using a custom comparison
object, operator== can already give weird results for std::map, so why
shouldn't it for std::unordered_map?
There's a problem if the containers' function objects aren't equal, but
I guess the solution is just not to use operator== in that very unusual
case.
> I believe the best thing, is to move the table to the .cpp, but I
> also I totally understanding the appeal of header-only libraries.
> Would you consider a configuration flag, whereby unless explicitly
> defined, your table is in the header, but for a user which controls
> its own site installation, a table can be generated into a .cpp and
> compiled into a library to be linked into programs using
> Boost.Unordered? I actually did write such a piece of code, it isn't
> hard, and you can specify the step (30% or 100%) and the range of the
> desired table. If you include this code into the example section and
> make the flag public, your users can choose what they prefer based on
> their requirements.
>
An optionally separately compiled part is fine. I think it's a good
idea. As for specifying the step, I'm not sure about that. It might be
better just to go for a fixed 30% step.
> What I hear from Pablo and John is that they're getting good support
> around their proposal (ok, they're biased too :)... Maybe you're
> right to wait and see what the committee will do. Hopefully, won't
> take long as C++0x is around the horizon and there'll be two meetings
> in Jan. and June. Somehow, I didn't think that Pablo's proposal
> (N2436) required concepts, but required traits instead. But I'm not
> intimately familiar.
>
Okay, if no one disagrees I'll change the swap implementation.
Daniel