Hacker News Reader

Comment by rcurry | Hacker News Reader

I spent a lot of years writing C++ code and really enjoyed it, it’s a fun language and you can pretty much do anything with it. But the problem I encountered with it was that it just became so wide in terms of features that you have a hard time keeping up - you can spend years using the language to build real software and then walk into a job interview and get demolished by all sorts of crazy stuff you didn’t even know existed. I remember purchasing the book “Modern C++ Design” by Andrei Alexandrescu and after reading it I realized it was time to find something else to do. It was an awesome book and I loved it, but all I did was work on trading systems and I knew I’d never be able to keep up with C++ interviews if that was the direction they’d be taking. But I still love the memories of working with it, so much damned fun.

View on HN

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

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.

I feel like I'm in the minority in not finding C++ complicated. C++ has gotten significantly LESS complicated c++11 and onward, I'd say. Inheritance hierarchies with private/protected/friends and virtual methods lead to significantly more complex codebases than flat templates and judicious use of constructors and destructors to handle things' lifetimes. When you've got a nice templated API, writing the client code almost feels like writing in a scripting language.

I'd say the only really hard part is understanding move semantics, but even then that's not really necessary and the verbiage on the internet is way too academic in that regard when it's really simpler in practice than it is when explained.

How much experience of C++ is required to understand that?

I guess being around since the language exists.

Just like looking at C# 10, Java 17, Python 3.9,... and making sense where the features or standard library calls came from.

If you have the luxury of making a clean break from old style C++, possibly. But, for example, in my case the only reason to touch C++ is precisely older stuff like native API’s. Because of that, I’m never writing purely modern C++. If I’m writing C++, it’s going to be a mixed bag of stuff with naked pointers, naked pointers to pointers, mallocs, and other fun stuff, meaning the subtle interactions between old and new features are always on my mind.

Just like other languages, C++ is not (that) complicated, if you happen to have full control of the code being written.

It is when you scale the team, or have a codebase that is being kept running since C++ exists, that the problems start.

However, to be fair and something that C++ haters tend to cleverly forget, trying to update a .NET Windows Forms application written in C# 2.0 into C# 10, Java 1.4 into Java 17 and so on, will face similar issues in complexity and language idioms.

If you build quality working programs that is what counts. Not that you can fly through some esoteric template shenanigans. When I being questioned by potential client we talk about what I've done and how (I design and build products usually from scratch). I also give references so people can check. If they start talking to me about can I write correct code in C++ or whatever other language right here I know I am in a wrong place. Normally such talk never happens.

You can take bits and pieces of C++ and never have to swallow the whole thing. I’ve kind of settled on C++11 as having all the tools I’d practically need. It’s got the right balance, IMO. If you’re interviewing somewhere that says they use every feature of the latest C++ in their software, run!

Ok but I'm not sure I could go back to compiling without modules.

> so wide in terms of features that you have a hard time keeping up

This is why I like the slightly more walled-in gardens of the JVM and CLR. For instance, when someone is talking about JSON serialization in C#, you could bet your life that they are referring to one of ~2 specific libraries and sets of methods.

It is a lot easier to build a community of shared understanding when everyone is playing the same game every day.

> For instance, when someone is talking about JSON serialization in C#, you could bet your life that they are referring to one of ~2 specific libraries and sets of methods.

I wouldn't bet on it, https://devblogs.microsoft.com/dotnet/try-the-new-system-tex...

Also try to talk about Java 17 to clueless group of devs still delivering stuff into production with Java 8 in 2021.

> Also try to talk about Java 17 to clueless group of devs still delivering stuff into production with Java 8 in 2021.

Id say it’s part cluelessness and it’s part that they just don’t care. They’re comfortable with 8 and don’t want to learn anything new (even if 8 is a slower runtime).

I fear that the community will never move on past 8.

You could say the same of people refusing to move beyond C89, Python 2, Perl 5,..... and that is the whole point of perceived complexity and current features of those languages in 2021.

> I wouldn't bet on it, https://devblogs.microsoft.com/dotnet/try-the-new-system-tex...

This would be the 2nd of 2 that I was referring to. The first would be Newtonsoft.Json.

Except this is a new API, not the 2nd one.

You have to modify code using System.Text.Json for the code generator based way, and it doesn't support all the features, enjoy the comments section.

> Except this is a new API, not the 2nd one.

> and it doesn't support all the features

I think there was a misunderstanding.

We do not use System.Text.Json because it doesnt support everything Newtonsoft.Json does. At no point did I intend to make the claim that these were somehow compatible implementations.

Our shop is stuck on Newtonsoft until Microsoft realizes that polymorphic deserialization is actually a really useful thing and not just a pedantic security concern.

Same for me, same. I spent years writing trading engines in C and C++ and have been rejected real quick because I don't use some modern template feature. A lot of stuff like the newer memory model and auto pointers are awesome but some of that template stuff is not for me when I look at the thousands of lines of assembly language, or worse still, huge chunks of code the linker does not throw out and is actually gets executed. I think it's just a 'flex' to attract candidates for particular culture fit so maybe, as another comment pointed out, it's probably best to steer clear of places that don't care for your real world experience in the field.

Andrei also found something else to do after writing the book!

What's the big deal with C++ being bloated (Linus, many experts don't like it) and I keep hearing that it has become unmangeable?

C++ doesn't force you to use everything it's got. Can't I just write basic C style procedural code in C++ and use OOP constructs if necessary? It is completely optional I think. Don't like templates? Don't use them. Set a policy in the team/company to avoid using advanced C++ features.

It’s not just about writing code though. If you want to properly read code you have to understand all the “advanced” features they have used.

I’m reasonably familiar with C++, but not so much with arcane template meta programs. I never write templates, but it still trips me up from time to time when I have to understand one.

I guess the messy ugly template headers could be hidden as compiler intrinsics, like in Go with its compiler blessed generics for standard containers. Or how C's printf is implemented as compiler magic instead of vardiac macros.

The complexity needs to be somewhere in the end. A charitable view would be that Cpp's approuch is more ... inclusive?

Yeah. All the arcane template stuff, even if I understand for sometime, you're bound to forget it as soon as you stop using it (which you probably should in most times).

It reminds me, every time I try to jump too implementation of some standard library method/class, it just seems like a completely different language to me. And C++ is the language I've most experience with.

Meanwhile, I jump to some Rust or Golang* standard library implementation, it makes perfect sense very quickly. Even though I just use them for hobby projects.

* Go is probably a bad example because it doesn't have any generics. But still love how much more approachable their stdlib code is.

A lot of that is that you have to protect against name collisions. You have things like c macro's so methods need to be wrapped in brackets{e.g (min)( a, b ); } and also internal names need to be prefixed with an underscore and start with a capital (e.g _Foo) as that is reserved.

The global namespace still exists so unqualified names that do not have a reserved id( eg _Foo ) cannot be used and need to be qualified (e.g ::std::(min)( a, b );). All this to protect against us.

Some codebases are easier to read, I would rank them from libc++, MS STL, libstdc++ is readability. libstdc++ also seems to have code all over the place and use far more inheritance for composition of things.

There is no reason to use "arcane template meta programs" anymore. That is all old-C++ stuff needed to work around missing language and library features. It has been literally years since I coded or even (visibly) used any template meta program construct.

That's not to say it doesn't exist in the implementation of the Standard Library. I just never have any need to see any of it.

Workable when you control the whole codebase, not so much when you have to deal with external dependencies or huge piles of legacy code that you're stuck with. I quite like writing C++ when it's just me or I have tight control, not so much when I have to deal with some of the large projects with code spanning 20-30 years of history and dozens of developers (some of which died before I even started my job) that I've worked on where it wasn't my call. Not that I have any specific traumatic experience in mind...

Admittedly such a situation is not entirely due to C++, but it didn't help. But again, I do quite like C++ especially nowadays.

I was thinking of that - I agree that's a problem. In my work, we have some basic dependencies and not much else - Boost libs and that's all.

May we should create a new subset of C++. It will be called C+.

> Can't I just write basic C style procedural code in C++

You can, but the bloat Linus is complaining about comes from the ability to do that. C is a real mess and is a large part of what is holding C++ back from being simpler (for both better and worse). C seems simple, but you lose a lot of abstraction ability when you use it.

C++ seems a lot more complex, but that complexity allows you to write abstractions that do exactly what you need. Modern C++ is the discipline that lets you write good abstractions, with exactly the control needed.

Don't take the above as some sort of statement that C++ would be simple with C - that is completely untrue. Only that C++ is moving to giving people the power to write the simple and powerful abstractions they need - but the nature of those abstractions are very complex and that cannot be avoided if you need to write them.

> use OOP constructs if necessary

THIS IS FALSE TO THE CORE! C++ is NOT about OOP. C++ is about writing the style that makes the most sense. OOP is good for a subset of problems, but a lot of problems can be solved better by not using OOP, and C++ supports that. If you think of C++ as C with classes you are making a large mistake.

Only takes a couple folks who want to use all the esoteric features of c++ at your workplace in a culture where nobody can tell them “no” (which is increasingly common) and big chunks of your codebase can evolve into unmanageable mess. Tbf i found the same to be true with Python but not with languages like Java, C# and especially Go

Go would be modern in 1992, not 21st century.

While C# is now on version 10, and Java on 17, if we account for the releases in 2021, the large majority of the world is still delivering .NET Framework (C# 6)[0] and Java 8 code into production.

When I use modern C# and Java, always need to give a mini-lecture on current state of the world.

[0] There are ways to use newer C# version in .NET Framework, but with some caveats.

Go 17 is being released in aug so clearly it’s almost as modern as java. I for one is jelly of innovative features such as gc tweaking whackamole and never expiring dns ttl default

Just wait for when Go 1.18 finally catches up with CLU, now that is blazing modern!

Avoiding the newer parts is the worst imaginable response.

If you write C code in C++, you will only have C code, and nothing better than C code. If you write Java code in C++ (which you can, and some do) you will only have Java code, and nothing better.

Leave the C parts behind. Leave the O-O parts behind. Lean into Modern C++, and reap the benefits of all the work put in to make the language better than C, better than Java (i.e. pre-C++98 plus GC), better than C++98, better than C++11, better than C++14, better than C++17.

Pointer arithmetic and inheritance are still occasionally useful; you can still wrestle in the mud. But if they show up in more than a few places in a program, you are Doing It Wrong.

I’m not convinced about your counter argument, let alone worst imaginable response.

All I’m saying is if a new feature is added to C++, it doesn’t affect me and I can choose to pick which features are useful. I can still keep it absolutely minimal. C with some useful libs, and occasional OOP.

Why this is the worst possible answer? Obviously it works for me, it makes sense to me and it is perfectly logical in my view.

Others have said the language bloat creates burden when you read other people’s code. That makes sense to me.

Care to elaborate more? If you want to harshly criticize, it’s fine but you need to say a bit more so I can understand where you’re coming from. I just see a bunch of rhetorical statements.

Nothing is added to C++ without demonstrating usefulness. There is no "language bloat". If you fail to find any of it useful, it can only be by not paying attention.

Yes, you can limit yourself to the C and Java subset, just as you can drive everywhere in first gear, can eat all your food raw, can crap in a hole. Just because you can does not make it a good idea. Objectively, the more your code looks like C, the worse it is, because you are inviting into it all of the flaws endemic to C code.

>> Nothing is added to C++ without demonstrating usefulness. There is no "language bloat"

"Bloat" doesn't require that the features are literally useless, merely that their usefulness doesn't justify their added complexity.

And for many people, a huge portion of C++ falls into this category.

Just look at the 18 different methods of initialization for an example of this. Or look at ranges, which seem to simultaneously be far more verbose than the alternatives in every other language, while having measurable negative impacts on compile times (that have spread throughout the stdlib, so even if you don't use them you have to pay for them). Ranges are certainly "useful" but the cost/benefit ratio is questionable.

Ranges had to be implemented without using the new language features that would make it easy and clean. Its authors had to use template-metaprogramming substitutes that are slow. As the language implementations catch up, the library can be upgraded and will get faster to compile.

There are new initialization modes that are simpler. The old ones still have to work. But you don't have to use the old ones anymore.

>> Lean into Modern C++, and reap the benefits of all the work put in to make the language better than C, better than Java (i.e. pre-C++98 plus GC), better than C++98, better than C++11, better than C++14, better than C++17.

Serious questions:

What subset of C++ is "Modern C++"?

Are there flags for C++ compilers to only allow modern C++ and generate warnings when non-modern C++ is used? (For example, if an older-style C++ idiom is used, the compiler might say: "use of Old_Idiom is deprecated. Consider using New_Idiom instead".)

I don't use much C++ and I have found the language daunting to learn because it is large, complex, and full of gotchas. A better subset that is enforced would help newcomers not get lost.

There are not such flags, but they would not be useful if there were. Real C++ programs link code of many different ages. Generally, you can only afford to make the new code, that you are writing now, the new way, and maybe modernize stuff immediately around it. The old stuff is typically well-exercised, and as long as it does its job you have no reason to touch it or, often, see it.

But it is for the new code that the most value is available.

Generally, if there are two ways to do something, and one appeared in a recent Standard, using that is usually the better choice. Cppreference.com helpfully tags each bit with when it appeared.

Regarding modern check flags: clang-tidy has its modernize-* flags

Reply on news.ycombinator.com