The Time Needed to Write “Effective Modern C++”

Ditto. I'm almost finished writing a book Ansible (self published on LeanPub), and most of the difficult sections have had the code samples ready to go for months. Getting the code organized an laid out in a logical fashion with appropriate, short intros, descriptions, and summaries requires much more effort than the code itself!

That is an argument to avoid const overloading, not constness generally.

I would say that constness is a massive boon so I use it on the vast majority of declarations. It reduces cognitive load by being able to assume that variables are not going to change.

Anecdotal, but a friend of a friend talked with Meyers, and Meyers said he has not worked on any large scale C++ programs in a while.

That being said, I have worked on large scale C++ projects, with a lot of people smarter than me, and the biggest criticism of Meyers' books and advice would be "necessary but not sufficient". I can't, off the top of my head, think of anything he recommends that would have been controversial amongst my peers.

>Is this guy actually writing C++ programs in the wild?

Well, I read one of his articles which you can find here: http://www.artima.com/cppsource/top_cpp_books.html

In it, he writes about his role with C++:

"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.

Given that I don’t really use C++, nor do I help specify it, you might wonder what I do do. Fundamentally, I study C++ and its application. I gather as much information as I can about the language and its use (from books, magazines, newsgroups, email and face-to-face conversations with developers and members of the standardization committee, experiments with toy programs I write, etc.), organize and analyze what I find, then I package my findings in concentrated form (e.g., books, magazine articles, technical presentations, etc.) for consumption for people like you—people who do use the language. Your job is to employ C++ as a tool to write useful software. My job is to discover and package the information you need to best apply that tool.

I like to think of myself as an outside observer, not too deeply steeped in the day-to-day travails of programmers and not too keenly focused on the minutiae of standardization, yet familiar with both. This series of articles, then, summarizes what this self-proclaimed outside observer thinks have been the most important contributions to C++ since its inception...."

His book is titled "Effective Modern C++," which necessarily contains opinions about what is effective and what is modern. Without practical experience writing software, his opinions won't be grounded, and so his advice won't be sound.

That said, I think he does a good job being even-handed. For example, his chapter on auto covers both advantages and pathological cases, and goes on to say:

First, take a deep breath and relax. auto is an option, not a mandate. If, in your professional judgment, your code will be clearer or more maintainable or in some other way better by using explicit type declarations, you’re free to continue using them. But bear in mind that C++ breaks no new ground in adopting what is generally known in the programming languages world as type inference.

So he is not excessively proscriptive.