Slashdot videos: Now with more Slashdot!
We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).
C++ might not end up being faster, but it certainly has no reason to be slower*. Well-written C++ and C should run at about the same speed. However, C++ has the advantage of allowing you to use high-level constructs when performance isn't as much of an issue.
* this is contingent on your compiler -- if you're using some compiler from a decade ago, some constructs (e.g. templates) may emit shockingly poor code
Off topic: But I really don't know why so many people use C++ for non-embedded. It's perfectly valid for many - maybe most - applications to trade efficiency for safety, so use a different language. Why pick one that accommodates all the power of C then constantly beat on the developers with a giant list of coding guidelines? When the greatest attribute you seek in a developer is pedantry then something's wrong.
C++ is great anywhere you need performance. Numerical computing, scientific computing, image processing, computer vision, machine learning, etc -- all of these benefit greatly from C++, as you can use it as a high-level language in the non-performance critical parts, but at the same time, be able to optimize effectively in the places where it matters.
So why isn't there a _standard_ library for safe string handling? (I know there may be several third party libraries) A library could abstract away the management of pointers to chars, things like growing and shrinking storage of the strings, creating string objects, destroying them, etc. without programmer ever touching a raw pointer to memory containing the string data.
Sounds like you're looking for C++ and std::string
Actually, it's still possible to have some bugs if you improperly use auto_ptr and shared_ptr, etc, but it's still much better than the classic method of allocation.
Of course, you're not using auto_ptr anymore, right? It's been deprecated in C++11, and there's little to no reason to use it in favor of unique_ptr. auto_ptr was the attempt at implementing unique_ptr semantics prior to having rvalue references as part of the language. As for the possible pitfalls... shared_ptr can still fall prey to cyclical dependencies, but unique_ptr is very good for enforcing ownership semantics.
And his birth certificate is not a sloppy forgery.
I find it amazing that there are still birthers out there.
Most of those games you quoted are very old and OP has probably played them all and is looking for something new.
Wasteland 2 comes out this Friday (9/19) and Pillars of Eternity is still in Beta. Unless you've got a time machine that's about as new as it gets.