Debugger Visualizers to Make Your Code Accessible

Working with C++ code can be difficult, and it's made even more difficult when the code isn't your own. Everyone agrees that documentation is necessary when sharing a library. But, as a user of a library, the documentation may not help when you want to know the current state of your program. If you're a veteran C++ programmer then you may easily find your way around memory readouts, putting print statements in exactly the right spots, or reading "between the lines" of the documentation. Some of us are not very experienced, or we aren't able to recompile the code with print statements, or the documentation may not help with the problem. Hopefully, the author had written an extension to connect their code to your debugger of choice. But odds are, they didn't. Debuggers are advanced tools, often overlooked when discussing the day-to-day aspects of writing C++ code. Without modifying the source code or recompiling, we can glean large amounts of information about the program state through our debugger. As library writers, or as people writing classes for others to use and reuse, we can and should be writing debugger visualizers. We can empower our users by lowering the barrier to using the library successfully.

This talk will outline how to make the most out of debuggers like the Visual Studio debugger and GDB. Briefly touching on the of how to start up the debugger, this talk will cover topics like automating and scripting the debugger, and writing custom visualizations like Visual Studio Natvis and GDB pretty-printers. This talk is here for you to get started with writing debugger visualizers. Let's make our libraries more accessible. Software is about more than just the source code.