Since writing the Natvis visualizers for Boost.Unordered, I’ve been thinking about how to test them. So far, I’ve only written semi-automatic testing. Run the “visualizer_tests.cpp” file in Visual Studio, break on the label called “break_here”, then inspect the Locals window. Since I already set up the code and checked it in, there’s no need to modify.

But this is still too manual for my liking. I want the CI to fail if I accidentally break the visualizers. Right now, I only know there’s something wrong if I check with my own eyes, or if someone files a bug report. To me, this isn’t good enough. It’s too much of a maintenance burden.

There’s this issue I’ve had when using std::apply, and I’m sure if you’ve written enough generic code, then you’ve experienced it too. If not, don’t worry, I’ll go through it fully. As specified in the standard, you can’t check whether a call to std::apply is semantically valid at compile-time. This would often be useful with a SFINAE idiom, whether using classic SFINAE or using C++20 constraints.

I recently wrote a SFINAE-friendly apply function for my C++20 expression template parser generator library tok3n. I thought the code was interesting enough that I wanted to write more about it here. I aimed to develop an explicit understanding of SFINAE-friendliness along the way.

This article is about my experience implementing GDB pretty-printers for the Boost.Unordered containers. You can read my related pair of articles on the Visual Studio natvis implementation here and here.

Importantly, in this article I’ll outline the techniques I used so that users can inject their own behaviour into the pretty-printers when the containers are using custom fancy pointer types. A “pretty-printer customization point” is my nickname for the technique I’m using, not an official term.

This is the 2nd article about my experience implementing custom visualizations for the Boost.Unordered containers in the Visual Studio Natvis framework. You can read the 1st article here.

This 2nd article is about the open-addressing containers, which all have shared internals. These are the boost::unordered_flat_{map|set}, boost::unordered_node_{map|set}, and boost::concurrent_flat_{map|set}. I’ll take you through my natvis implementation in this article, omitting the methods and details that the 1st article already covered.

Recently I’ve been working on implementing custom visualizations for the Boost.Unordered containers in the Visual Studio Natvis framework, to provide an identical debugging experience in the Boost.Unordered containers to what we get for the STL containers. Here is the file.

This has been a tricky process, and I found the natvis documentation online to be lacking a few key pieces of information I needed. With this (and subsequent) article, I will take you through the experience of implementing the natvis file for Boost.Unordered.

Continuing on my series on my expression template parser generator library…

So far I’ve defined the AnyOf parser, that checks whether the first character of the input string matches any characters from a given set. This is one of my “primitive” parsers. I’ve thought of 2 other “primitives” to act as a basis for the library: NoneOf and AllOf. After that, let’s expand on the idea of a “Parser” in general.

I talked about this in a lightning talk at C++Now 2023. I want to go into more detail here.

It’s exciting in a masochistic way I guess. A sort of self-schadenfreude. Somehow I found a bug in a major compiler! Frustrating for my workflow obviously, but it feels like a compliment, in a strange way.

Long story short: I hit a bug in MSVC where (spoiler) a non-type template parameter gets zeroed out at run-time but not at compile-time. Long story long: let’s talk about how I got there.

Last time I had a brief explanation of the library I want to design. I want to create parser combinators using expression templates, where all information is in the parser types themselves, with no data members.

Writing this library has been a hugely enjoyable experience. I’m sure I’ll find flaws and issues to be addressed, after writing these articles. So let’s start simple and work up to the more complex cases. How simple can we get? How about a type that parses exactly 1 character.

But first, a preamble

This is my backstory before the recipe in this metaphorical cookbook.

I was first introduced to the idea of parser combinators in a CppCon talk not about parser combinators, at least not as the main feature. Ben Deane and Jason Turner’s famous “constexpr ALL the Things!” talk opened my eyes to the magic that’s possible with parser combinators, and I wanted to do it too! I tried and failed to replicate what they had, then gave it up.