(Original Review, 2001)

Back in the day, I started programming AMOS on Commodore Amiga500. It was almost exactly like QBasic, but was able to do more powerful graphics and sound in an easier way, though still extremely similar. Because of how slow those CPUs were, I had to always try to find ways to make the programs run as fast as possible. And then I started programming QBasic on a 200Mhz PC, still being focused on trying to get as much power as possible in my programs. Around 2001 I started with C++ by using Stroustrup’s book, and even though we had a lot of power, I was manically trying to make everything as simple and efficient as possible, to get all that power out, even though I was on a powerful i7 with a GTX780. Whenever I thought of using "smart pointers", I always thought that I'll just use ordinary, low-level pointers, because I don't want to incur any overhead whatsoever. Check if a pointer is OK? Screw that, it'll cost me! Better to make sure it doesn't happen, rather than to check if it did happen, by being smart about it. I do simulations and experiments, and things like 3D game engines, and I wanted every little bit of performance I could get. I wanted the code to be perfect, so I kept re-writing everything, and I was afraid of using libraries that might have unnecessary overhead, like error checking/prevention, so I re-invented the wheel over and over. It's important to note that it was a hobby back then (still is, but less so). I wouldn't do it like that if I was going to share the code, or release a product (there was no psychologist available who could have helped me get over this obsession...)

The main problem is what I feel must still be tackled towards the end of reading Stroustrup's book: there's a lot of baggage from C, not on the spec, that's the least of the problem, but on people's minds when they code or of course when they reuse old code. When I started learning C or C++ programming, and it wasn't that far back, there was either material on pure old C or C++ that was almost identical to C with a few class definitions thrown in (and C fanatics pushing newbies to learn C instead of C++ for every project doesn't help and is simply insane).
At the end of the day C++ is abysmal if it's written like C since the only thing it gains is a couple of class definitions. The true power of newer languages is automation and abstraction above the micromanagement of C. Sure, that micromanagement might make sense when writing the Linux kernel, but for almost every other project it's a total waste of time since it doesn't even increase performance.

I've always felt there is no way around it that C++ has some serious design limitations and the developments of the last years only try to cope with some of them. It is no wonder that there are so many code analysis tools and everybody uses some of them. Apart from that, cross-compiling is still an issue, compiler output is cryptic and setting up a C++ workflow on Windows is ridiculous. I think Rust really has something. On top of that, the syntax is hideous. C syntax isn't perfect and certainly can be abused, but it's simple. With C++, they keep on extending it. How many new ways do you need to do casts?

C++ is not just for higher level it goes pretty deep and down to the bits as well, you can also code assembly with C++ - don't think small with C++ it is a tremendously large language and nearly impossible to master everything involved with it, people who have their PhD's still don't know everything that can be done with it - Bjarne even says he is surprised with what people can do with it - and the standard is always changing, what I am saying is - you should always be learning and never get stale, if you think you know everything go read "exceptional C++" - if you are good with that go run a project on github or get a job, if you have a job learn from those who are great.

Bottom-line: C++ allows a programmer to make mistakes, assumes he knows what he's doing, gives too much freedom and it's bad for safety. If you will learn 10 different programming languages, you will understand what I'm talking about. What can C do that C++ can't? You can do pointer arithmetic in C++, also unsafe casting, arithmetic overflow before allocation, corrupt the heap, return a local by reference, the list goes on, for both languages. The nice thing C++ gives us is smart pointers, but if you want to stay safe you have to subset the language, which raises the question: why use C++ then instead of a higher-level language that more accurately reflects your usage? Yes, C is a little more comfortable, "simpler", as you say. But that's only until you make big programs, where C allows you to make more errors/bugs, and it has less abstraction possibilities, so there's more stuff you need to keep in your head. The good thing is that you can use C++ in the same way you use C, if you want to, and you can mix stuff quite freely. If you tell your compiler that you're strictly using C, then you have less freedom. Even if you tell your compiler to strictly use C++, you can still use C++ in the same way you'd use C. OOP is optional, though it's sort of the point with C++. I think the difference between C and C++ becomes clear when you look at type-casting, for example. In C, when you want to type-cast, you might write "int x = (int)a_float;", to cast that float to int. But in C++, you have to explicitly state what kind of type-casting you're using. Reinterpret, dynamic, static, const. And the thing is that those 4 different type-casts exist in C, as well, but you never explicitly state which one you're using. In C++, it'd be "int x = reinterpret_cast(a_float);". As for "the debate", I didn't know there was one. C++ is clearly a better choice than C, since you can still do what C does, but you've got more, as well. Some say "but C is faster", and that's in a sense true, but C++ can be as fast as C, if you avoid those few things in C++ that make it slower. The freedom is there, without any drawbacks. That makes C++ the obvious winner.

That's why I'm all for using Python. Much safer. ( )