> Precisely, C++ code is usually not riddled with all kinds of bugs and buffer overflows. </sarcasm>
Sarcasm aside: having more experience with C than C++, I find my C++ code rather significantly more resistant to buffer overflows, off-by-one errors, etc; it's when I'm interfacing with primarily C-based APIs that force me to do pointer math and so forth that I hurt myself. I don't have the confidence to write in C (fairly) quickly and correctly as opposed to C++. In this way C++ does come from that earlier era that the grandparent poster referred to: where Java didn't exist yet and the managed options weren't particularly fast, but C++ (even in its nascent form) could help you provide yourself tools for encouraging correctness that C could not.
Today, it's a different story. The STL (particularly as of C++11) is advanced to the point where it's very possible to write code that is, relative to Java or other managed languages, generally very fast and definitely very portable, while retaining pretty solid guarantees of safety. And I either I or the compiler are more likely to either notice my mistakes, which I inevitably make, in C++ than C.
You probably meant the stdc++, not the STL. But I agree, in C++11 one can use smart pointers which help avoiding many memory management pitfalls and make memory ownership mode more explicitly defined through the language itself.
In this case I did mean the STL-derived bits specifically. C++ collections, iterators and <algorithm> are awesome. When you're used to C for writing native code and your options are arrays, linked lists, or oh-god-I-hope-I-wrote-this-hashtable-correctly, this stuff is amazing. I guess they're not called the STL anymore, but I tend to use the term to refer to them specifically.
I actually only very rarely use smart pointers in my main C++ project; my game has a simple lifecycle and wouldn't benefit from them much, though I could probably stand to use unique_ptr more than I do. The primary place I use them is to use std::auto_ptr to clean up after myself when dealing with try-catch blocks--I standardized on them before really understanding unique_ptr and my use of them is single-function-limited so I kept it consistent. The game itself is modeled on a stack-based state machine and I'm able to pretty easily reason about my object lifetimes within each state without smart pointers.
Sarcasm aside: having more experience with C than C++, I find my C++ code rather significantly more resistant to buffer overflows, off-by-one errors, etc; it's when I'm interfacing with primarily C-based APIs that force me to do pointer math and so forth that I hurt myself. I don't have the confidence to write in C (fairly) quickly and correctly as opposed to C++. In this way C++ does come from that earlier era that the grandparent poster referred to: where Java didn't exist yet and the managed options weren't particularly fast, but C++ (even in its nascent form) could help you provide yourself tools for encouraging correctness that C could not.
Today, it's a different story. The STL (particularly as of C++11) is advanced to the point where it's very possible to write code that is, relative to Java or other managed languages, generally very fast and definitely very portable, while retaining pretty solid guarantees of safety. And I either I or the compiler are more likely to either notice my mistakes, which I inevitably make, in C++ than C.