Closed k3DW closed 3 months ago
Some preliminary comments:
BOOST_UNORDERED_DISABLE_SSE2
and/or bulding on x86 mode. I understand this is known and non-regular layouts will be addressed in the future.table_core::group_type::regular_layout
.__mo_bit
etc.?__issen_regular_layout_true
etc.?base1
, base2
and base3
to base0
, base1
and base2
. Also, I'd add a comment these are for Natvis, because the perplexed reader may find they are not used anywhere in the code.table_iterator::operator*
is invoked?end()
displays as "it <struct at NULL>", which is not bad if compared with std
containers ("it (<Error reading characters of string.>, -842150451)"). Closed-addressing end()
, though, looks uglier ("it ({...}, ???)"). Not sure we can/should do anything about it, anyway.BOOST_UNORDERED_ENABLE_STATS
is defined. @pdimov @cmazakas your opinion on this?operator*
mentioned above, which would suggest supporting fancy pointers is indeed possible.Thanks for the comments. I'll address each one of them below.
__match_occupied
intrinsic. It seems like this is too confusing, so I should use the full name instead of abbreviating.__is_sentinel
. Similarly, it looks like I should use the full name here for clarity.baseN
aliases are following the same naming scheme as boost::unordered::detail::compressed
, which has base1
and base2
aliases. I'll leave a comment explaining these are for natvis. Let me know if I should still change the new baseN
aliases, given the information about detail::compressed
.table_iterator::operator*()
. This shows dereferencing the member table_iterator::p_
, which has the type table_iterator::table_element_pointer
. Without fancy pointers, this is a regular pointer that can be dereferenced as a primitive operation. This is not calling any user-defined operator*()
.end()
iterators.operator*()
, which would be disallowed in natvis. I think more discussion of supporting specific types of fancy pointers (like boost::interprocess::fancy_pointer
for example) should come after the initial natvis implementation here. Then we can reassess.Non-SIMD layout does work for me, so we can sort that out in private. Typically when I switch, it requires an entire "rebuild" in Visual Studio, not just a "build".
I confirm it works for non-SIMD and/or x86 on my side after rebuilding. Thank you!
"mo" just means "match occupied" [...] Likewise "issen" means "is sentinel".
OK, no need to change names if it works for you.
The
baseN
aliases are following the same naming scheme asboost::unordered::detail::compressed
, which hasbase1
andbase2
aliases.
All right, makes sense. Please do add the comment, though.
The link you provided does not show table_iterator::operator*() [...]
Thank you for the explanation. I stand corrected.
Supporting individual types of fancy pointers is possible, but I will make the case that support for generalized fancy pointers is impossible as a single unified implementation[...]
Yes, you're right. I got sidetracked by my wrong assumption that code functions could indeed be invoked, which is not the case as discussed above. So, let's forget about fancy pointers for now.
One additional observation:
table_iterator::increment
. Turns out that the version of increment
for regular layout is there for performance reasons, and the non-regular-layout version should work equally well. So, you probably can retain only the non-regular-layout loop --the mo and issen functions, however, need be versioned for regular/non-regular.OK, no need to change names if it works for you.
I disagree. If there's a point of possible confusion, I want to remove it. I don't want to be the only one who can maintain this code. I'll change the names.
So, you probably can retain only the non-regular-layout loop...
Huh you're right. That removed over 100 lines. Good catch.
An automated preview of the documentation is available at https://249.unordered.prtest2.cppalliance.org/libs/unordered/doc/html/unordered.html
An automated preview of the documentation is available at https://249.unordered.prtest2.cppalliance.org/libs/unordered/doc/html/unordered.html
Partial work on #162. This applies to containers with raw pointers as the allocator pointer type. This does not account for fancy pointers.