This is a header only library offering a variety of dynamically growing concurrent hash tables. That all work by dynamically migrating the current table once it gets too full.
My attempt to adopt this library for the project's use has ended up in several fixes.
1. Build fix:
the call braces were missed in one place, and it turns out that a static field requires an explicit definition, so luckily there's inline key in c++17.
2. Empty pointer fix:
I don't have a good understanding of what's going on there, but I saw 1 << 48 inside the pointer value very frequently, so I have protected all the places where the pointer is fetched from this markable-taggable reference.
Maybe it's just supposed to be the mark bit, i don't know. Please take a look at it, maybe ptr_split itself should be fixed.
Also, I suggest to redesign ptr_split to use masks and shifts, and to make accessors to those fields.
The reason is that the bit fields layout is implementation-defined:
On big-endian architcture, "full" can be not what you expect (one might expect a pointer, if tag and mark are zero)
The bitfield layout and alignment is implementation-defined, so it may vary from a combination of abi and compiler.
Maybe, here it's not a case, if a pointer is never assigned through "full", but the 48'th bit problem suggests a need for a look of some thoroughness. I wonder about the author's opinion.
3. Fix include paths
When used as a Library, the root tipically won't be in the include_directories list. So the relative paths should be used. I have also fixed the paths in the examples, though it's not required there
Hello!
My attempt to adopt this library for the project's use has ended up in several fixes.
1. Build fix:
the call braces were missed in one place, and it turns out that a static field requires an explicit definition, so luckily there's
inlinekey in c++17.2. Empty pointer fix:
I don't have a good understanding of what's going on there, but I saw 1 << 48 inside the pointer value very frequently, so I have protected all the places where the pointer is fetched from this markable-taggable reference.
Maybe it's just supposed to be the
markbit, i don't know. Please take a look at it, maybeptr_splititself should be fixed.Also, I suggest to redesign
ptr_splitto use masks and shifts, and to make accessors to those fields. The reason is that the bit fields layout is implementation-defined:Maybe, here it's not a case, if a pointer is never assigned through "full", but the 48'th bit problem suggests a need for a look of some thoroughness. I wonder about the author's opinion.
3. Fix include paths
When used as a Library, the root tipically won't be in the include_directories list. So the relative paths should be used. I have also fixed the paths in the examples, though it's not required there
Best regards