I can see this as an attitude to stay the course using/leaning it. But not as an end game; “you’ll never get it, don’t even try!” tThe idea that you as a team might develop a large piece of software, but have an unknown feel for how much more there is that is unknown, is scary to me.
And a bit ironic. I lived through the static compile type/dynamic late type wars. There was this argument that with C++ (and similar) you knew and had some compiler ratified certitude you could count on. But if you’re telling me that a junior/intermediate dev can write code, perhaps making head scratching design concessions to get the thing to compile, he might make code that appears to run in the common case, but has unexpected behavior in other as of yet demonstrated areas, because they can never hope to have enough knowledge of the language to build a semi accurate model to know what to expect, then we’re really no better off than those late bound interpreted hippies with their weird metaprogramming VMs.
Whoah, I think you completely mis-read my intention.
My point is that C++ offers users a lot of tools. You don't need to use most of them to solve most problems. Just start with simple tools: functions, classes, standard templates, etc.
That 10% effort will solve 90% of problems.
If you find a problem that can't be solved with the simple tools, then start looking into more advanced features C++ offers and use them if appropriate.
That is why no-one needs (or should try) to keep all of C++ in their head. It's not necessary for most problem solving.
It's of course fine to be enthusiastic about it and learn some new things just for the sake of learning. But it's not a requirement to know all of C++ to write C++.
>> But it's not a requirement to know all of C++ to write C++.
You just need to know as much as everyone else on your team and all of the libraries that you are using.
"Within C++, there is a much smaller and cleaner language struggling to get out". Yes, that quote can be found on page 207 of The Design and Evolution of C++. And no, that smaller and cleaner language is not Java or C#. The quote occurs in a section entitled "Beyond Files and Syntax". I was pointing out that the C++ semantics is much cleaner than its syntax. I was thinking of programming styles, libraries and programming environments that emphasized the cleaner and more effective practices over archaic uses focused on the low-level aspects of C." Source: https://www.stroustrup.com/quotes.html#:~:text=%22Within%20C....
The question is then, "which 'cleaner and more effective practices' are being used in the code you write and maintain?"
Only someone who knows too little about C++ would say something like that. Different features can interact in subtle and unexpected ways and that can bite you at runtime without any warning at compile time.
And a bit ironic. I lived through the static compile type/dynamic late type wars. There was this argument that with C++ (and similar) you knew and had some compiler ratified certitude you could count on. But if you’re telling me that a junior/intermediate dev can write code, perhaps making head scratching design concessions to get the thing to compile, he might make code that appears to run in the common case, but has unexpected behavior in other as of yet demonstrated areas, because they can never hope to have enough knowledge of the language to build a semi accurate model to know what to expect, then we’re really no better off than those late bound interpreted hippies with their weird metaprogramming VMs.