Re: [boost] [hash] regular behaviour of hash function for double values

Subject: Re: [boost] [hash] regular behaviour of hash function for double values
From: Daniel James (dnljms_at_[hidden])
Date: 2012-02-04 04:52:19

On 3 February 2012 01:07, Topher Cooper <topher_at_[hidden]> wrote:
>
> My misunderstanding.  I argued that the choice required that a user wishing
> some different trade-offs would need to modify or rewrite a large complex
> piece of code instead of a small, simple one.  Your response was that they
> could just use a completely different, non-standard conformant, library
> instead of customizing the code.  I'm not sure what you are now saying
> (really) -- that I was right and that there is no reasonable way for library
> users to choose different performance trade-offs?

It isn't that bad. STL style containers are pretty well established so
containers are often replaceable. For example, Google's hash
containers are written to have a similar API to the standard
containers, although they add some extra requirements to their
elements. I don't think they implement anything from C++11 (yet?).
Bizarrely, they even supply local iterators, even though they don't
really do what they should, and I don't think anyone would miss them.

To some extent, you need to accept reduced performance when using
generic components. They do tend to be less efficient than more
specialised ones. The STL and Boost have both reduced that cost, but
it is still there. An example of this is allocators, fully supporting
C++11 allocators can introduce inefficiencies or prevent optimisations
because of the need to support custom pointer classes. A certain
amount of template magic can reduce that cost though. Something I've
considered in the past is adding a type trait for hash functions which
specifies when power of two buckets can be used, although I'm always
wary of introducing extra complexity to the implementation.