To clarify, Scott never was a practicing programmer, but a book writer who capitalized on quirky details of C++. As he explained, there is less need of such books nowadays due to the vast availability of resources on the web.
Its kind of like, saying Donald Knuth was never a Computer Programmer, but some old faculty professor, with too much time on his hands, who capitalizes on puzzles and the natural complexity of computational theory. :-)
It also does not address the core point of the post.
At the moment for C++ the scene goes like this:
- For every traditionally challenging feature/issue of C++ advocates will say it has already been fixed on the latest standard. So you always feel to be a proper C++ developer you have to be a "Modern C++ Developer"
- You are supposed to know and use the modern features of the language but also use it according to what I call "the C++ on top of C++" called the "C++ Core Guidelines".
https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines
I printed them last week and its a 498 pages PDF. So of course you will have wait and rely on compilers/linters keeping up with it.
https://docs.microsoft.com/en-us/cpp/code-quality/using-the-...
They are not done yet, and we will soon move to the next phase in complexity in the daily life of a C++ developer. Having to troubleshoot the correct implementation of these automated checks by the different automated tools.
Like many, I have to sometimes use C++ professionally. Every time I do, I feel like I am a candidate to the Darwin Awards.
I’ll begin with what many of you will find an unredeemably damning confession: I have not written production software in over 20 years, and I have never written production software in C++. Nope, not ever. Furthermore, I’ve never even tried to write production software in C++, so not only am I not a real C++ developer, I’m not even a wannabe. Counterbalancing this slightly is the fact that I did write research software in C++ during my graduate school years (1985-1993), but even that was small (a few thousand lines) single-developer to-be-thrown-away-quickly stuff. And since striking out as a consultant over a dozen years ago, my C++ programming has been limited to toy “let’s see how this works” (or, sometimes, “let’s see how many compilers this breaks”) programs, typically programs that fit in a single file. (make? Who needs stinkin’ make?) My living is based on C++, but it’s not by virtue of the programs I write in it.
Donald Knuth wrote TeX and related tools which are huge/complicated software over and above his Algorithms/Computer Science Theory contributions. He stands alone in his greatness.
Scott Meyers is not even in the same league. He is a "consultant" (with all the good and the bad which goes with this profession) and in the same group containing the eXtreme Programming/Agile/Scrum crowd.
https://www.artima.com/articles/the-most-important-c-booksem...
I’ll begin with what many of you will find an unredeemably damning confession: I have not written production software in over 20 years, and I have never written production software in C++. Nope, not ever. Furthermore, I’ve never even tried to write production software in C++, so not only am I not a real C++ developer, I’m not even a wannabe. Counterbalancing this slightly is the fact that I did write research software in C++ during my graduate school years (1985-1993), but even that was small (a few thousand lines) single-developer to-be-thrown-away-quickly stuff. And since striking out as a consultant over a dozen years ago, my C++ programming has been limited to toy “let’s see how this works” (or, sometimes, “let’s see how many compilers this breaks”) programs, typically programs that fit in a single file. (make? Who needs stinkin’ make?) My living is based on C++, but it’s not by virtue of the programs I write in it.
It’s not by virtue of any intimate association with the language’s standardization, either, because I’ve never been a member of the C++ standardization committee, I’ve never been on the committee’s mailing lists, and I’ve never attended any standardization meetings. My knowledge of the inner workings of the committee—including the things that have had a significant impact on it—is based on what I’ve read and heard from others. This means that I may be ignorant of important forces that shaped C++ as we know it, because those forces may have been felt only within the committee.
Wow! This answers many questions that i have had over the years.
I never understood people's fascination for Scott Meyers books (and i own a lot of C++ books). I felt that it sort of clued you in to the microdetails/dark corners but failed to teach actual big picture programming using those same features.