And that's the real problem with C++. You can spend 20 years solving real problems with it and still feel like a noob when you take a look at "idiomatic" template code from the standard headers.
On the other hand, people like Scott Meyers have spent their lifetime and careers explaining its intricacies, without solving any real problems.
You can spend 20 years solving real problems with it and still feel like a noob when you take a look at "idiomatic" template code from the standard headers.
It can be misleading to think of standard header code (especially template code) as "idiomatic C++". It'd be better described as "idiomatic standard-library-implementor C++", since the folks implementing stuff in std are operating under a whole set of constraints that don't affect ordinary C++ programmers. Arbitrary user-defined symbols that could be in scope, user-provided types that could have overloaded operator-comma, etc.
Yes, and I think this same principle is roughly true for a lot of programming language implementations. It's one of the reasons it pays off to know some details about your implementation -- People should always keep this in mind.
Designers and implementors are traditionally under a very different set of constraints than "average users" (who in this case are programmers), though their goals do align. But this leads to very different set of assumptions, optimizations, and tools being available. Things that would generally be overkill are suddenly very viable and worthwhile goals to achieve (e.g. micro-optimizations add up repeatedly so they're very worth it, vendoring is much more useful to control dependencies/scope of bugs), and vice versa.
So I wouldn't be extremely miffed if you look at libstdc++ or libcxx or <whatever> and find it somewhat unkempt or gross compared to average code. It's often very much not-average. In fact it's likely given careful understanding of the constraints that code exists under -- you'd come up with similar results.
I think it boils down to a wider philosophical question that deserves some discussion in software development circles. The question basically is "Should we get obsessed with our constantly evolving tools at the cost of devoting significantly less time to understanding the intrinsic problems we are trying to solve?".
Each time I hear a discussion between programmers, it is always these arguments of whether build tool A is better than build tool B, or whether VCS A suits their workflow better than VCS B, or how cool is the latest language feature. I never see programmers discussing the merits of their solutions, regardless of the language or environment.
We talk about tools all the time because it's fun and it's something we all have in common. Every once in a while something like clang comes along and it can change everything.
What we don't have in common are the exact problems we are trying to solve. That's where design patterns and other higher level concepts become useful. Because the problems and solutions are so context specific, they happen on mailing lists. Tool discussions, on the other hand, are more generic and I think that's why you see them in more places.
> Sometimes people think they know their favorite language, but most would fail a language puzzle quiz.
But that is especially true for C++. People who are confident in knowing it often lack the fundamental C knowledge (i.e. pointer arithmetic, the complete C type system, the subtle conversion and promotion rules, etc.), but would insist on knowing C++ very well just because they know how to define classes, virtual functions and throw a shared_ptr or a vector or a map at every problem.
And most people that say that they know C and how simple the language is, cannot differentiate between their compiler extensions and what is written in ANSI C.
Nor can they correctly point out all the cases of expected semantics, UB and implementation specific behaviour.
Regarding the fundamental C knowledge, part of it just leads to bad C++ code.
Make the language easy to use without any mental burden? But you do realize programming is not easy, especially when you're aiming for high performance. How can you make a language easy to use "without any mental burden"? Programming is hard, programming well and with performance in mind is even more so. Some things you just can't magically make easy.
I actually feel the exact opposite when I program in C. C is so bare that most of my time is spent building the correct constructs I need to solve my problem. C++ on the other hand has a decent set of high level features that makes it easier for me to focus on the problem.
You can write a C++ program to solve a problem that looks almost exactly like the C program you would write. But C++ brings a couple of nice features, like resource management with constructors/destructors and type-safe data structures that you just can't have in C.
On the other hand, people like Scott Meyers have spent their lifetime and careers explaining its intricacies, without solving any real problems.