This is kind of a pattern with “design flaws in C++” if you’ll excuse the phrasing. C++ conflates a lot of different concerns with each other, so you end up wit

This is kind of a pattern with “design flaws in C++” if you’ll excuse the phrasing. C++ conflates a lot of different concerns with each other, so you end up with some reasonable objective (enforce invariants) and some reasonable way of achieving that objective (constructors & destructors) and it works well enough 90% of the time but the other 10% of the time it's a problem. Then there's a ton of design patters that crop up to manage the 10% of use cases where the language doesn’t quite give you the right tools for the job. For example, access control. In C++, access control boundaries are classes, which is a reasonable choice except there are a ton of situations where this is the wrong choice, so you have “friend”. Some C++ designers will tell you “friend” is a code smell, which is true, but the fact is you can’t always avoid it. In languages where access control is defined relative to modules this is rarely a problem. So I say that C++ conflates access control boundaries with class boundaries. Another example is syntactical blocks and variable lifetime. Object lifetime is an important concept in C++, but object lifetimes often don’t line up with the extent of syntactical blocks, even if it doesn’t make sense for the objects in question to have dynamic storage duration. My hot take here is that C++ is a very opinionated language, in the same sense that Go and Python are opinionated languages, it’s just that C++, Go, and Python have strong opinions about different aspects of the language. Another difference is that people in school falsely equate traditional object-oriented design with good design. This makes sense, because it’s much easier to teach object-oriented design than it is to teach good design.