I guess it's a warning to people who try to do this and find that the debugging experience may not be what they expected it to be. Nothing against the author, of course.
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.
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.
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.
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.
> but in my experience this the subsystem is usually not where you'll find the error; more often it's in your own code
More often perhaps, but compilers and their standard libraries are complex pieces of software written by human beings - and it's not that uncommon to encounter them, especially if you go a bit off the beaten path or are an early adopter.
I know Hacker News guidelines say you're not supposed to ask if someone's read the article but... did you even read the article? What part of the article is not about C++ and macOS?
19 comments
[ 3.1 ms ] story [ 38.8 ms ] threadkudos to the clarity of this simple effort in the "tangled forests" that are Modern C++
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.
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.
Some mistake. The article contains nothing on this subject.
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.
More often perhaps, but compilers and their standard libraries are complex pieces of software written by human beings - and it's not that uncommon to encounter them, especially if you go a bit off the beaten path or are an early adopter.
True. But notice the word Debugging is missing there.
Yup. No offence taken.
> What part of the article is not about C++ and macOS?
None of it.
But what part /is/ about debugging that?
None of it.
Did you miss this part?
Debugging - the process of identifying and removing errors from computer hardware or software.
But what do think /is/ the meaning of "debugging" here, if not the common-usage one seen in the dictionary?
- https://www.jviotti.com/2021/07/23/a-deep-dive-on-macos-univ...
- https://www.jviotti.com/2022/02/21/emitting-signposts-to-ins...
- https://www.jviotti.com/2022/11/28/launching-macos-applicati...
- https://www.jviotti.com/2022/02/24/attaching-lldb-to-product...