Everything wrong with C++.
 

Funny and to the point video on C++. 2 hours long. Glad that I'm not the only one that has gritted my teeth while using it.

https://www.youtube.com/watch?v=7fGB-hjc2Gc

Itching c++
 

https://port70.net/~nsz/16_c++.html
- too many features (but abstractions and expressivity is not that good)
- missing useful features (safety, concurrency, closures, module system,..)
- implementation is difficult (language tools and compilers are bad)
- feature X is broken, dangerous, has too many special cases, noone understands the semantics.
- feature X is good, but it is abused in c++ or does not work well with other features.
- not enough compatibility: code gets broken because of language changes, compiler fixes, deviations from c99, posix.
- senseless compatibility: c design (preprocessor, type system,..) is unsuitable for the feature set of c++.
- complexity: difficult to maintain, debug, fix, understad and reason about code (..written by others).
- complexity: learning and using the language requires too much effort.
- c++ is hideous (errors in implicit runtime mechanisms cannot be handled, encourages breaking abi,..)
- c++ is slow (compile, link and run time), big (language tools, src code, compiled code) and ugly.
... and more

A little bit old, but quite interesting, C++ Frequently questioned answers: https://yosefk.com/c++fqa/
In particular, Defective C++: https://yosefk.com/c++fqa/defective.html

C++ programmer's guide to undefined behavior, part 1 of 11: https://pvs-studio.com/en/blog/posts/cpp/1129/

Encyclopedia of things considered harmful, about C++: https://harmful.cat-v.org/software/c++/

Linus Tordvals' opinion of C++ is to enjoy: https://harmful.cat-v.org/software/c++/linus

While I didn't watch the whole thing; a lot of what they said you could say the same about C. I can't say I'd agree that C was never meant for large projects, how would an OS like UNIX be considered a small project? That's why C was developed in the first place as far as I know.

Just because you can do something, it doesn't necessarily mean you should. You can jump off a cliff too, are you going to?

You should repeat the same value used in more than one place? I hope you never have to change it, god forbid it's the version of your app or library...

Clearly they prefer Java instead, whata rant if there ever was one... Linus has gotta be insanely jealous if he watches that...

:shrugs:

Is it bad? maybe
Is the developer experience worse than Python? Yes.
But it is not the "The worst programming language of all time". I can think of a few worse languages.

Also my favorite language is objectively worse
https://en.wikipedia.org/wiki/Brainfuck

This is how you print "Hello World!" (you can use an online compiler to confirm):
Joking aside though, I did not see the entire video, but he has a lot of good points.

I watched the first two minutes.

The problem with C++ is that it is trying to do too much. C++ should not try to compete with Rust or Python. C++ is already extremely good at what it does.

The trick is to use a subset. I write C++98 with select C++11 features, and libraries that cover my needs. I have not experienced breakage when compiling with the current language standard.
Ed

There is only one thing wrong with C++ - or rather one root cause of all these problems and annoyances - it is an unnatural and unworkable hybrid of two clashing principles. C is a highly flexible and efficient language giving a programmer the most intimate control over the code. It was designed for writing operating systems - and in the good old days when they still cared about such things as code size and efficiency. But there is a price to pay: C code is not easy to read and maintain and it offers ample opportunities for shooting oneself in the foot. OOP is a technique to develop reliable code faster at the expense of its performance and efficiency. The result, of course, is the language which is both inefficient and difficult to work with - and all because there was a huge base of C fanatics who'd rather cut off their penises than use Delphi and won't accept OOP unless it had C in it.

By considering each individual command line C program as a separate small project.

https://en.wikipedia.org/wiki/Unix_Philosophy
People put in provocative statements like that just to grab attention and encourage others to comment. And it works, as you demonstrated.

For the record, C was created to support the creation of Unix, the original, in the 1970s. It came WAY, WAY before Rust or Python. C++ was created in the 1980s (release as C++ in 1985) to resolve some of the issues with C for utility and application projects, and allow some of the OOP the author had introduced.
Python was not even conceived of until 1989. Rust started as a side project no one heard about until 2010. Who is trying to compete with whom now? Not at all a bad way to work. Using features or libraries "just because they exist" has led to very fine, concise, elegant, efficient, bad code with difficult to detect errors (because the cause may be deeply buried in compiler or library code).
I have worked Perl (and Pascal, for that matter) the same way, ignoring modules that exist for a specific function but that complicate my use case under the hood. Better to code an explicit and direct solution myself, that is more correct for my specific needs.

From what I've read about "Brainfuck" (and going by it's very name), it doesn't appear that it was actually designed as an alternative to any serious language that people would actually use for any serious projects. So I'm not sure it would qualify as an alternative.

I was considering it as all the user-space utilities, kernel, etc as being parts of the same project. But yes, if you consider the different "components" as being separate and independent projects, then yes, you would have a point. Although, it's interesting to note that they say "the early versions of Unix", which implies that the later versions of it weren't considered to be small projects.

Although, I'm not sure Linus would agree that C was never meant for large projects, as I really don't think you could call the Linux kernel a small project by any means.

I do find the part:

to be funny tho. Not because it's not true, but you can just picture a group of people sitting around the room pondering it, if you know what I mean :p

Have to agree with you there, clearly you're very much correct about that! Although, and that said, it wouldn't make me inclined to leave a comment in their video though.

They're wrong in the video linked in the OP when saying you must have a header for every source code file, you're not actually required to have one. You could put everything into the same source code file if you wanted to and the compiler wouldn't complain and would let you do it. Don't get me wrong, I'm not advising people to do it that way, and I certainly wouldn't be doing it that way. As personally, I don't think the preprocessor is a bad thing, but it's like any other feature of the language, you need to be sensible about it. I for one favor using a #define preprocessor directive over a const or a variable when you are using either a default value or, and particularly the same value in multiple places in your code. Whereas, Java, C#, etc, you would be forced to use a const or a variable instead as far as I know, and variables take up memory, whereas a #define preprocessor directive doesn't take up any memory, therefore there's no overhead.

All that said, I do have to agree with EdGr in only using a subset of it, which was my point in making the comment in my post #3 quoted below:

And I would agree with lvm_'s comment that the root cause as far as I can see for the complaints about C++ would stem from the two clashing principles, as lvm_ said.

We have an application at work that the programmer used as much c++ features as possible. It is a problem to maintain for people down the road. He didn't adhere to the 'KISS' principle which is my motto. I use the basic constructs and ignore all the 'fancy'/'clever' ways. Readability over cleverness anytime. That said, I am currently coding a home SDL3 project in straight 'C'. What fun to use simple syntax to get the job done without all the overhead of C++/Rust. I apply the KISS principle to Python as well. I don't use many of the advanced language features either as I feel they aren't intuitive to someone else looking at the code. Again readability over cleverness unless there is a 'really really' good reason for it.

It isn’t an alternative, it handles everything worse, including performance.
It is Turing-complete and you can think of it kind of an implementation of a Turing machine, at least when it comes to loops, (which I love as a Math person).

Its real value lies in learning how to build a compiler.
Writing a compiler for a language with only eight basic instructions is way more simple (and can easily be done in a weekend) than trying to build a compiler for a language with a complex syntax like Python, C++, etc.

It's an interesting question considering its complexity, that is, the number of functions it contains (let's say, how rich it is, how easy it is to express yourself in it).
The problem is that the richer a language is, the more complex is it, the harder it is to learn and use, and the fewer people who can use it professionally.
And the question is, why, what and for whom do you create (a programming) language? For dummies? For professionals? For the average user?
How can you achieve anything? By exploiting all the available power of the language, or by using only a few basic commands (and creating inefficient solutions)?

By the way, AI will eliminate the need of the languages sooner or later.

If you are properly creating a language, at the planning stage at least, you are not creating the language for PEOPLE. You create a programming language to solve a PROBLEM. It should be a tool, and the tool is designed for specific work. A properly designed language should make solving that problem more natural and elegant.

Pascal and Modula-2/3 were designed for TEACHING concepts, and are excellent at expressing those concepts. C was designed for construction of operating system tools, and fit that use case perfectly at the time. FORTRAN was designed for mathematics and matrix mechanics, and is STILL the best tool for that use case. COBOL was designed for managing document paperwork and mathematics, and is hard to beat at what it does best even today.

C++ was created to express a form of C enhanced to use objects and inheritance. It also served as a bridge between OS and OS Tool coding and application coding. (The success of C++ and SMALLTALK inspired the insertion of OOP structures and logic into other languages, including Pascal and COBOL.I am not sure that was any improvement.)

Automated Incompetence (AI) has no creative component. A human coding community will always be required to feed the back end database with new logic and creative structures. If we ever achieve real Artificial Intelligence that may change, but I estimate that we are at least a century away from that point.

Do any of these cover the pseudo-smart "C++ grammar is not context free!" complaint that I used to hear all the time on Slashdot? Or have people forgotten about that?

Probably centuries... Thing is, what is 'old' is 'new' to the up and coming wanna-be programmers. I see it all the time... So an AI solving a problem 'looks' new even though it is just crunching old data. An advanced search engine... I see that all the time in the gun forums I frequent too. Answering the same 'o questions time and time again. Answers that was said/written years and years ago... Or a youngster comes up with a electronics project and is excited about it, and, sure enough, someone pops in and says, "I did that years ago with 555 chip"... The wheel of time just keeps turning...

It was in Pascal at least. Worked out well when we were using Delphi and now Free Pascal/Lazarus. IMHO.... The OOP part... As with C++, I feel a lot of the so called advanced features aren't necessary. C++, should be just C with some OOP to solve particular classes of problems that may come up. That is now I use it anyway.