I think this misses the point of what "Modern C++" is about. It's absolutely about best practices, and that's a good thing. Go back to the mid '90s. There wa

I think this misses the point of what "Modern C++" is about. It's absolutely about best practices, and that's a good thing. Go back to the mid '90s. There was a lot of awful C++ code out there, and a large part of that was the language was dangerous for many people who didn't know how to use it safely or effectively. Some of that legacy persists today in old codebases. The STL and the C++98 standard library improved upon that, but there were still dozens of interesting ways of shooting yourself in the foot. Then we had people like Meyers who wrote whole books explaining the dangers and how to write code to avoid them. These were the best practices, and they are hugely helpful. I use them daily in my work, preventing subtle bugs, leaks, undefined behaviour and random crashes. These turned C++ into something which could be safe and effective to work with, provided you didn't ignore the guidelines and do anything irresponsible. C++11 and 14 improved upon them, and again Meyers brought out a book to explain a whole new set of pitfalls to be aware of. I agree with your assertion that it's to some extent dogmatic. But I don't agree that it's cargo culting (though some people may be). Over the last 25 years, we've collectively learned that there are some things which you must never do (e.g. throwing exceptions in destructors), and some things which you should or must do. Like the rule of three or rule of five, RAII, or how to implement Java-style interfaces with virtual inheritance and various deleted operators and constructors. Experience has shown that this is the right way to do things, and you'd better have a good reason for deviating from that. Languages like Java benefit from being restrictive and only have one safe way to do things. That's not true for C++, where you can do what you like even if it will explode in your face, and having a set of best practices we all agree on make things safe and efficient to work with. Certainly on the team I work on, being able to refer people to Meyers and say: "this is the way to do it, and this is the rationale" is beneficial and educational to the people concerned, as they get a better understanding and appreciation of the language subtleties, rather than their work making the code segfault or do the wrong thing. For the minority who are cargo culting, I'd rather that they followed the dogma and wrote safe code even if they don't fully understand the rationale for doing so, when the alternative is writing unsafe and buggy code. Unfortunately, there is a minority that doesn't care to understand, and for them a set of strictly enforced rules is required to avoid disaster.