Debugging the C++ standard library on macOS (2022)

Of course, LLDB is more likely than not to be useless when debugging complex templated code from the standard library :(

I love that the author dives right in to learn C++ and I endorse their enthusiasm.

However I am not sure reading the standard library sources is a great way to learn early on. Those sources have a lot of speciality code, and weird head-standing in order to handle various obscure corner cases, different architectures and the like. And it’s so great they do!

When you’re still learning C++ all that extra care will probably add to the learner’s confusion rather than reduce it.

And in fact, very few people need to write code like that. When they do, they will often resort to obscure corners of the C++ standard which were added for library writers (hence the common response to a new standard, “why did the committee waste time on an obscure feature like that?”).

Also these libraries typically rely on compiler-specific features that may not even be documented.

I don’t mean to discourage anyone from reading the library sources! But perhaps they are not the best place to start.

What part of this isn't about debugging the C++ stdlib on macOS? It talks about the special version of clang in Xcode. It has macOS-specific options. It gets into the details of doing this with Mach-O files. Almost no parts of this post isn't about the c++ stdlib and essentially all of it is specific to macOS.

The standard library may not be the best way to learn C++ for several reasons.

1. The standard library is allowed to do things that you are not allowed to do. Because the standard library goes hand in hand with the compiler, it can take advantage of extensions or implementation defined behavior or even what is undefined behavior in the standard.

2. Because it has to be as resilient as possible despite people using macros and naming things, the standard library uses double underscores "__" a lot to name variables. That is not something you should do because those are reserved for the standard library implementer

3. Because the behavior of classes and functions is specified precisely by the standards documents, there is often less commenting that would be normal

4. Because of backwards compatibility, the standard implementation of certain things can be sub-optimal. For example, std::regex is slower than non-standard implementations and may have security issues with untrusted input. Another example is the hash containers unordered_map. The standard kind of forces you into a certain implementation, where others can be much better. The Abseil flat_hash_map containers can be much more efficient than std::unordered_map

This all is not to say the standard library doesn't contain a wealth of information. It does. However, you may need more C++ experience before you can figure out what is a good technique for you to use in your own code, what is suboptimal for you to use, and what is dangerous for you to use in your own code.

If you want a kind of project that is along these lines, I would recommend the following.

1. Implement std::string (but use a different namespace). This will teach you about memory management, constructors, destructors, STL containers and algorithms.

1a. Implement the small string optimization for your class. Make sure you avoid undefined behavior. This will teach you about unions and type punning rules and when you are allowed to cast pointers in C++ without running into undefined behavior and type alias rules.

2. Implement std::tuple. This will teach you a lot of meta-programming techniques.

3. Implement a multi-threaded queue with push and pop. This will teach you about mutexes and condition variables.

3a. Make it lock free. This will teach you about atomics.

I guess what chrisjj might have meant is that "debugging" usually starts with a bug, a or symptom. So in case of debugging the standard library, it usually is a problem in your own code that you cannot explain and try to blame on an error of the subsystem. In those cases, having access to a source-level debugger can be useful but in my experience this the subsystem is usually not where you'll find the error; more often it's in your own code.

So in case of this article, ask: what is the symptom of an alleged bug in the standard library that the author is trying to uncover?

This article is more about using the online debugger to explore parts of the standard library. Which is interesting, but as others have pointed out probably not the best way to familiarize yourself with a language or library.