> I only have a guess as to what a `shared_ptr` or `unique_ptr` type is, and I certainly don't know when to use them, and concepts/traits outlined in the STL do

> I only have a guess as to what a `shared_ptr` or `unique_ptr` type is, and I certainly don't know when to use them, and concepts/traits outlined in the STL documentation seem to be some sort of generalizations that the STL might provide default implementations for, but might not? What exactly is the syntax and/or type of a lambda function and how do they interact with C function pointers? etc., etc. And that's exactly my point though! `shared_ptr` and `unique_ptr` solve (or, at least, simplify) a lot of the memory management problems endemic to all C code and old C++ code. And they've been around for over a decade now. I would absolutely be willing to spend some time with you to teach you what new things are, what they do (and what problems they solve), and how to use them without introducing new problems. I think several one-on-one teaching sessions would help you a lot with that. But one-on-one teaches you and not the thousands of other old-experienced C++ developers also in your shoes. > I get the sense that C++'s evolution has been driven by esoteric corner cases that a handful of developers have encountered and the language & STL design has been driven by those cases. While some of the C++ evolution fits that category... I would also add that a lot of changes in modern C++17, C++20, or C++23 are aimed directly to the masses of C++ developers doing "everyday" work. shared_ptr and unique_ptr are definitely not esoteric corner cases: they're driven to specifically solve memory management problems that have directly contributed to some very significant CVEs in many thousands of products.