A new fast hash table in response to Google’s new fast hash table

Re:A new fast hash table in response to Google’s new fast ha... by jcelerier on Tuesday May 29, 2018 @12:56PM (#17180904)

> I looked through the code and o_O there is a lot of C++ boilerplate.

This boilerplate allows me to choose between std::unordered_map and flat_hash_map in my whole code just by toggling a compile time switch in my code. It ensures that the data structures has the same API than all other C++ containers.

[ Parent | on HN ]

Re:A new fast hash table in response to Google’s new fast ha... by titzer on Tuesday May 29, 2018 @01:21PM (#17181146)

I understand what it is for. YMMV but for me C++ is pretty much a constant mental stack overflow when reading the guts like this. It seems like C++ libraries are getting more and more configurable in a way that hurts readability and understandability and library designers don't seem to recognize there is a fundamental tradeoff here.

[ Parent | on HN ]

Re:A new fast hash table in response to Google’s new fast ha... by kwillets on Tuesday May 29, 2018 @03:04PM (#17182051)

I actually have separate implementations of an algorithm with and without templates; the template one is for benchmarking with different combinations of options; the non-template one is for readability, and it's only about 60 lines.

[ Parent | on HN ]

Re:A new fast hash table in response to Google’s new fast ha... by jcelerier on Tuesday May 29, 2018 @02:20PM (#17181700)

> It seems like C++ libraries are getting more and more configurable in a way that hurts readability and understandability and library designers don't seem to recognize there is a fundamental tradeoff here.

well, I mean... if it was not configurable, it would not really be useful, except for toy examples, and for those the default std::unordered_map is more than sufficient. To be useful, a hash table implementation at least needs to allow to configure the hash function and the comparison operator.

[ Parent | on HN ]