Re: [boost] [review] Review of Unordered library begins today December 7

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