There has been a few fiddly bits and a few surprises. But for the most part it doesn’t seem as hard as I’d expected or been led to believe. Actually it feels pretty nice.
Why do people hate on C++? Presumably I’ll find out if I try to get more advanced. Having said that I’m finding I don’t really need much more than what I’m using already.
Honestly it doesn’t feel too different to javascript.
So why don’t people like C++?
I personally will avoid C++ if possible because it has too much complexity, too many "gotchas", and there are better choices available (Rust, Go, Ada, C, etc.).
Some people like C++ and that is fine. They can use it. I will use something else if at all possible.
https://en.wikipedia.org/wiki/Criticism_of_C%2B%2B
A 275-page book about how initialization works in C++: https://www.cppstories.com/2022/cpp-init-book/
- the headers files are a pain and feel unnecessary.
- the build systems are annoying. So many of them, none is great.
- no common package manager.
- the language has too many paradigms and is a mess unless you restrict yourself, but usually the C++ code base you work on is not yours.
- memory management is hard.
- the segfaults.
- the compilation error messages.
- the templates hell from the standard library or boost.
You can read informed critiques of programming languages by people who have experience, and there's no shortage of experience with C++ and books about it, because it became popular as soon as it came out and we now have over three decades of experience with C++.
I don't know what you mean by "people" hating C++, or why anyone would care. You can certainly find rants and posts complaining about C++, but you can find those about anything. Study people who know better and form your own judgments.
Even for those that it fits, C++ used to be a relatively simple language. They could understand all of it (if they go back that far). Now it's not, and they can't. There are tons of corners of the language, and virtually nobody knows all of them, still less how they interact with each other. This can lead to some extremely counterintuitive behaviors in your code. Many people don't like that.
Personally, I like C++. It's the only mainstream language with destructors, and I consider that a very useful thing for resource management. (If the only resource you have to worry about is memory, garbage collection is probably a better answer. But if you also have to close files and release semaphores, destructors can make that less of a headache.)
Still, if I'm working on my own thing, I'm not sure C++ is the first language I reach for. Depends on the problem.
So, if you ask me, I feel bad about Perl. Nobody seems to talk about that anymore.
As someone who writes way too much C++, I will say that there is nothing wrong with the language. There is an abundance of tools to detect and fix problems, and quite a lot of libraries out there for every need.
The worst stuff is the building and linking. I remember early on how angry I got when I learned that the order matters, but in reverse order too. On top of that, the language basically has no way to include other libraries on its own.
https://stackoverflow.com/questions/3363398/g-linking-order-...
This answer highlights the poor design.
And this is totally by the book, the size of 'int' is allowed to deviate from compiler to compiler by design. This comes from the 70s C that was suppose to become "portable assembly" and back then, apparently, portability meant compiling without errors. So C++ addresses this issue and proposes types with fixed length. You can now write your types explicitly. Like this: uint64_t(uint16_t(50000) * uint16_t(50000))
And get 18446744071914584320. Because, nevertheless the new fancy types, the promotion rules from PDP-7 still apply. Your expression is getting cast to the next signed standard type that can accommodate `uint16_t` and this is still `int`. So you get -1794967296 and only then convert it to unsigned `uint64_t` number.
Fiddly bits and surprises will keep on coming.
I've been writing in C++ for, what, 17 years now?, just yesterday I was rewriting a unit test with floating point data into integers. It was something like this: "1.234, 0.123, 5.678" and I wanted "1234, 123, 5678". So I just removed the decimal points and let the heading zero in 0123 hang. 0ops! In C++, heading zero marks octal notation, and 0123 actually means 83.
But the thing responsible for the most rants is C++ static polymorphism. Since you don't have Rust-like type traits, the only way to ensure that one piece of code will work with another is to compile them both together. This means that for every minor change in an underlying library, you have to recompile all the dependies to see if their tests still work and this gives you enough time to write a rant or two.
Which was a great way to gain adoption, by being born as UNIX language at Bell Labs, it quickly got adoption from C compiler vendors, making them all ship C and C++ compilers in the same box.
Which is also its greatest pain point, because no matter how much we want to improve the language without fully breaking compatibility, there will always be someone that will write C++ code that could be as easily compiled by a C compiler, thus killing any attempts to safety.
Those that complain about its complexity, aren't wrong, however any language with similar longenvity has similar levels of complexity.
The lengthy ISO C++ standard also includes the standard library, so for similar baselines, who can master the knowledge of Python 3.11 + standard library, Java 21 + standard library, C# 12 + .NET standard library + MS frameworks, F# + .NET standard library + C# interop +..., and so on for all languages with 20+ years of evolution.
Even the "basic" C, actually requires knowing compiler specific stuff, and POSIX for most deployment scenarios.
My job doesn't require coding in C++ directly, it is more of a native libraries kind of thing, and the language I reach for most of my hobby coding.
One day that might be Rust, but it still lacks too much stuff for the hobbies I enjoy coding for, V8/CLR/JVM/LLVM/GCC internals, GUI and GPGPU programming.
- compilation is a pain to setup and support along the project compared to Rust or Go, the lack of package manager is quite sensible and the experience is not warm and comforting.
- Modern and (consensually enough) tooling in my opinion. (On this matter, C++ beeing widely used in the industry, you have a no-willing-to-count number of softwares to test your C++ application. The list is way to long of closed or open source framework. Got a new job ? Congratulation you probably earned new framework to get in hand with).
- The compilation time.
This last one is not something you do not find in C and FORTRAN project:
- In the industry (does not apply to open source project), most of the C++ developpers knows the C++ of their graduation year and nothing else. You can find a lot of documentation/manuals telling you how to produce C++ before 2011 (big bang time for C++) and even now, you have poor documentation on how to produce modern C++ with C++20 features. The modern doc/manuals is a small amount of the accessible knowledge you can find on the internet about C++. Therefore, a poor amount of people are able to write modern and clean C++. The ability for educate juniors to modern C++ is quite low.
Now that you are here, something to the credit of C++:
- Very few languages hold the comparison with C++ regarding performance. Fewer have those performances with an object oriented structure of the code (to not say none in the embedded industry). There is a good reason to have most of the Gaming motors written in C++.
This is one problem. I've been programming C++ on and off (mostly off) for about 15 years, and I keep running into things in code bases that I've never seen before and have no idea how to deal with. The potential difference in coding styles between two C++ developers is far larger than probably any other language I know. If I get to write C++ the way I want, using only the features I know, then it's fine. Once you start getting more developers involved you are going to need a very strong lead to keep everyone in line and consistent.
C++ is also complex and interacts with other complex things in sometimes unexpected ways. It will also let you shoot yourself in the foot in very complex and unexpected. By far the hardest bugs I've ever had to deal with in my career have all been C++ bugs.
Finally building and linking a non-trivial C++ project always ends up being a janky pain that eats up more time and sanity than it should.
The being said, I don't mind C++ and use it quite a bit. Although these days most of the C++ code I write is libraries callable from python with pybind, rather than 'pure' C++ applications.
Languages like Go are designed so that someone who's not familiar or wants to use these patterns can write safe and good code. And ALOT of people are complete idiots at c and c++ in a good fashion. You can see the most obvious and horrible programmers making critical things like routers who just have the most blatant bugs or bad practices. And what you don't know, you don't know. So these people exist in bliss pushing shitty horrible, bug ridden code. ANd using these coding styles which prevent that are extra tedious and annoying.
For libraries, try to use VCPKG to find and build new ones to statically link. You also need to learn about compiler definitions, like declspec. And need to worry about alignment on some things as well.
...that would be because Javascript was developed by people who wrote C/C++ :)
Netscape was written mostly in C++ back in the 90s because it was the Language of Choice™
So the devs that worked on Javascript borrowed a lot from C++ in terms of syntax, structure, etc
Likewise, Java looks a lot like C++ because the folks at Sun were writing in C and C++ for the SunOS/Solaris operating system, and all the Unix utilities that supported it
And C++ looks a lot like C because Bjourne Stroustrop started with C, and added-on
And C looks a lot like B because they started with B and made something new/better
PHP looks a lot like C/C++ (and perl), too ... because they started with those as inspirations
"New" languages tend to "look like" the languages the designers/developers already use :)
You don't see that type of complexity in any other language, and it's because of a tragic marriage of low levelness and object orientedness, and the language tries to hide some of the complexity behind implicit behavior which actually generates more complexity.
It's also very old and has accumulated a lot of lessons learned without changing the old behaviors due to backward compatibility handcuffs, resulting in the characteristic "the most obvious thing is the wrong thing" syndrome.
I like it too though.
cout << this << fucking << garbage;