Comment by belter | Hacker News Reader

Comment by belter | Hacker News Reader

Parent Full thread

You could be Scott Meyers, write:

====================================================

1992. Effective C++: 50 Specific Ways to Improve Your Programs and Designs.

1995. More Effective C++: 35 New Ways to Improve Your Programs and Designs.

1998. Effective C++, Second Edition: 50 Specific Ways to Improve Your Programs and Designs.

2001. Effective STL: 50 Specific Ways to Improve Your Use of the Standard Template Library.

2005. Effective C++, Third Edition: 55 Specific Ways to Improve Your Programs and Designs.

2010. Overview of The New C++ (C++11)

2010. Effective C++ in an Embedded Environment

2014. Effective Modern C++: 42 Specific Ways to Improve Your Use of C++11 and C++14 ====================================================

and you would not be able to understand modern C++ anymore...

"The Errata Evaluation Problem"

http://scottmeyers.blogspot.com/2018/09/the-errata-evaluatio...

"As you may know, I retired from active involvement in C++ at the end of 2015, and in the ensuing two and a half years, I’ve forgotten enough details of the language that I am no longer able to properly evaluate bug reports regarding the technical aspects of my books. C++ is a large, intricate language with features that interact in complex and subtle ways, and I no longer trust myself to keep all the relevant facts in mind. As a result, all I can do is thank you for your bug report, because I no longer plan to update my books to incorporate technical corrections. Lacking the ability to fairly evaluate whether a bug report is valid, I think this is the only responsible course of action."

Wow, what a response. Thank you for taking the time to reply and I think you did a far better job of summing up the challenge of being a “modern C++ programmer” than I could have dreamed of. I had no idea that Scott Meyers had bailed on the language, I’m honestly stunned to read that.

What is our option now? Rust? I love it but it is moving 5x the rate of c++. Static analysis may save us in this one. Good tools will tell you when you did something the "old" way. I'm not sure which part of our pipeline that is. Cppcheck, coverity or some clang checker probably.

I would love compiler options for enforcing better practices and prohibiting old style code (no using bare new/delete, stricter implicit casts, etc.) It wouldn’t fix everything but would go a long way.

It’s a little bit of a peeve of mine that people just decided on new languages instead. But it is what it is, and I am probably not knowledgeable enough to really judge.

You can think of C++17 as a new language which happens to be able to compile most C++14, C++11, and C++98 programs.

The trouble is, if every new version is _technically_ its own new language, and if you have to break compatibility a little, why not just break a lot and fix everything?

It's not like C++ was ever known for ABI stability anyway.

The benefit is that ability to compile that old code, even if it takes some flags or marking it unsafe or whatever.

There is a lot of old code that will never be rewritten but is still valuable, and I believe we will waste a lot of time just language-shifting entire ecosystems as new languages come and go.

Look at python 2 to 3. There are still packages out there on python 2 that haven’t been migrated. And thats mostly the same language!

(Note that my view is colored somewhat because I am a scientific programmer)

For those that don't want to upgrade, why not use a pinned compiler? Everyone else does this with other languages, and overall I think the benefits outweigh the costs.

Rust? I love it but it is moving 5x the rate of C++. Static analysis may save us in this one.

Yes. Rust is complicated, but the compiler is unusually good at telling you what you did wrong. Before it results in a crash.

The underlying problem with C/C++ is that it still doesn't have a decent array story. " char * " is so 1970s. That can't be fixed without breaking so much. All you can do is try to paper over the problem with templates. But the mold always seeps through the wallpaper. Look at the example in the original posting that reads:

    FILE* fp = fopen(fname.c_str(), "r");

There it is, access to a raw pointer. Why is that even allowed any more? You ought to have to wrap "Unsafe" around it, or something.*

Because it needs to support 40+ years of legacy code. What's wrong with the more modern array types?

Because the underlying OS API expects a char* as file name.

Rather, the underlying OS requires an array of bytes terminated by 0 which can be hidden behind a decent API. The type being poor at expressing this is not a limitation of the OS but of the C type system. E.g in zig this would be `[*:0]u8` which is "a pointer to a region of memory of unknown length terminated by a 0 sentinel value". It's still a pointer but nothing says the type system can't track more state around it.

So why isn't the Linux API properly encapsulated for C++? Rust does that.

C++ got off on a weird I/O direction. That

   file << item << item;

syntax never really caught on. Someone liked Currying too much.

C++ has a great array story - `std::array<char, N>`. `fopen` is a C API, so yeah you have to pass it C-strings. Note that Rust has to do the exact same thing (albeit calling `open64` rather than `fopen`), you can see it in the source for the stdlib here https://github.com/rust-lang/rust/blob/master/library/std/sr...

> Why is that even allowed any more? You ought to have to wrap "Unsafe" around it

There have been a few different projects aiming to introduce 'proper arrays' into C, but they never get traction, even when carefully designed for good backward compatibility. C is seemingly just too resistant to change. Here's Walter Bright's suggestion. [0]

Aside: why is the word story so popular on Hacker News these days? We can just say C doesn't have decent arrays. We aren't discussing its history, we're discussing a specific technical facet of the language.

[0] https://www.digitalmars.com/articles/C-biggest-mistake.html

>Rust? I love it but it is moving 5x the rate of c++.

I'm not sure this is true. It has been a year since the last really significant change to the language, whereas C++ is adding Ranges, Concepts, Modules, and so on and so on. The pace of change has slowed way down in Rust and sped way up in C++, it almost feels like C++ is moving "faster" now or they are at least close to matching pace.

But a lot of the Rust efforts at the moment are really just closing holes in the language - things that you would expect to be able to do, but haven't been able to do due to compiler limitations. Generic Associated Types and Const Generics both kind of fall into that category. The rate of true "new feature" development is way down.

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.

Right; direct to the point!

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.

To say Scott Meyers never was a practicing programmer but just someone who capitalized on quirky details of C++...

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've commented regarding "bailing the language", i.e. it was as a writer, not as a developer. Scott mentions himself that he is not a dev, and there is nothing wrong with this:

https://www.artima.com/articles/the-most-important-c-booksem...

From the above linked article by Scott Meyers;

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.

Confession by Scott Meyers from the article linked by "zerr";

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.

What other endeavor could you take a break for a few years and then come back and still basically be at the same place where you left off? Pro golfer? Concert pianist? Physicist?

Hell I forget what half my codebase does in a matter of weeks and have to go hunting through documentation.

This means that Rust can also die once an "Effective Rust" is published and the author retires!

Yes, and everyone should watch Scott Meyers's awesome presentation at a D conference with the title "The Last Thing D Needs". (tl,dr version: The last thing D needs is someone like him, really to be so insanely convoluted, as C++ is, as to need someone like him.) Link to the video: https://www.youtube.com/watch?v=KAWA1DuvCnQ

I think it is pretty obvious that Mr. Meyers never actually programmed / used C++ himself for any real projects. That he would abandon the language after only 2.5 years of nonuse makes sense to me.

Reply on news.ycombinator.com