Implement natvis visualizations

[k3DW]

Partial work on #162. This applies to containers with raw pointers as the allocator pointer type. This does not account for fancy pointers.

[joaquintides]

Some preliminary comments:

• Non-SIMD layout does not work for me. This can be tried defining 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.
• Can you explain to me how regular layout detection works? Note you can directly rely on table_core::group_type::regular_layout.
• What does "mo" mean in __mo_bit etc.?
• What does "en" mean in __issen_regular_layout_true etc.?
• I'd rename 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.
• I learned from your article that Natvis doesn't allow calling code functions, yet we have this, where table_iterator::operator* is invoked?
• Open-addressing 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.
• No documentation and release notes yet. I can provide these if you'd like.
• Proabably not worth it, but we can also display stats when BOOST_UNORDERED_ENABLE_STATS is defined. @pdimov @cmazakas your opinion on this?
• For the record, fancy pointers are not supported, and probably we won't ever support them. Yet, I'm puzzled by the use of operator* mentioned above, which would suggest supporting fancy pointers is indeed possible.

[k3DW]

Thanks for the comments. I'll address each one of them below.

• 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".
• Yes this is exactly how I detect regular layout. See here for example.
• "mo" just means "match occupied". It's a helper intrinsic for the actual __match_occupied intrinsic. It seems like this is too confusing, so I should use the full name instead of abbreviating.
• Likewise "issen" means "is sentinel". These are helpers for __is_sentinel. Similarly, it looks like I should use the full name here for clarity.
• The 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.
• The link you provided does not show 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*().
• I'll see what I can do about the visualization of end() iterators.
• I'll also work on the docs and release notes. No need to provide it. I'll take feedback on that when I do it.
• I'm not familiar with the stats, but we can talk about that as well.
• 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. As I mentioned a few points up, this is not calling any user-defined 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.

[joaquintides]

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 as boost::unordered::detail::compressed, which has base1 and base2 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:

• I see you've written two versions of the element loop, one for regular layout and one for non-regular, basically replicating the code in 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.

[k3DW]

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.

[cppalliance-bot]

An automated preview of the documentation is available at https://249.unordered.prtest2.cppalliance.org/libs/unordered/doc/html/unordered.html

[cppalliance-bot]

An automated preview of the documentation is available at https://249.unordered.prtest2.cppalliance.org/libs/unordered/doc/html/unordered.html