@Alpha_ProgDes has it right; use what you know first. Learning another language "because it's probably got better performance", before you have anything published in the languages you're already good with, is premature optimization - and as we all know, premature optimization is bad.

And for what it's worth, I'd avoid C++ like the plague anyway. If you DO pick up C++, avoid the STL containers like the plague - their performance is absolutely abyssmal.

@Alpha_ProgDes has it right; use what you know first. Learning another language "because it's probably got better performance", before you have anything published in the languages you're already good with, is premature optimization - and as we all know, premature optimization is bad.

And for what it's worth, I'd avoid C++ like the plague anyway. If you DO pick up C++, avoid the STL containers like the plague - their performance is absolutely abyssmal.

@Alpha_ProgDes has it right; use what you know first. Learning another language "because it's probably got better performance", before you have anything published in the languages you're already good with, is premature optimization - and as we all know, premature optimization is bad.

And for what it's worth, I'd avoid C++ like the plague anyway. If you DO pick up C++, avoid the STL containers like the plague - their performance is absolutely abyssmal.

Talking about premature optimisation and then saying to avoid the standard library for performance reasons is a massive self-contradiction.

Actually, no, it goes to prove the point. Many times, when deciding to optimize early based off of minor observations, without really completing the solution, you just muck it up. In this case, OP is asking to switch to C++ because (essentially) "that's what everyone uses"; having a java background, OP would expect the C++ STL containers to confer that same sort of naive "all native code is fast" performance benefit, when in actuality, they're the fastest way to murder C++ code.

Write first, optimize later. OP's java will quite likely be faster than their C++, since they already know their Java, and the best patterns/weaknesses in the language. If they write their Java and finds that it is, in fact, too slow (or nobody wants to run Java), then they can look to a new language.

Unless they really honestly just WANT to learn a new language, just for the sake of learning it, which is an entirely different conversation.

I didn't even mention Java. I'm just saying, if you use C++ without the standard library you are making life difficult for yourself.

Switching language is hardly an optimisation. Switching to a different container type is trivial in comparison.

@GD.NET: tldr:C++ rox/sux, Java sux/rox. The end. This debate is older than some of the people on this board.

Also, as for containers, BOOST for the win.

@OP: You're going to get bored of hello world and the amazing joys of console text output REALLY quickly.

Get reasonably good with that first. Then try some graphics programming.

I'm assuming you're going to program in Windows so you will want to go with DirectX. You'll want the Direct X SDK.

Now, there is steep speed bump in the learning curve as you go from console to Windows programming, and that is the windowing system itself. This doesn't have to be a stumbling block in your coding pursuits. Find a good tutorial site. I like CodeProject.

http://www.codeproject.com/search.aspx?q=directx&doctypeid=1

Best thing to do is find a SERIES of Direct X tutorials. This is that whole "gradual learning", "bit by bit", "walk before you run" deal.

Once you have a quasi-firm grasp of DirectX, find a sprite repository and experiment with animating.

http://charas-project.net/charas2/index.php (This one's all sorts of fun.)

Sound/music is important. Or you can tell your users to hum while they play. Find a free sound/music repo and add background music and sound effects to your project.

Bit by bit. Little by little.

And then one day, not today, or even next week, you'll make the move to 3D. Make some 3D models. Spin them around like a planets in a solar system. (My CG instructor made us do a 3D solar system with the "Utah Teapot" with the sun, three planets and the moon). Go with Blender for now. Sculptris also, but mostly for heads. If you're a college student, you can get a LEGIT copy of Maya 3D and other AutoDesk products free. Free is good.

Go make us proud.

And for what it's worth, I'd avoid C++ like the plague anyway. If you DO pick up C++, avoid the STL containers like the plague - their performance is absolutely abyssmal.

And for what it's worth, I'd avoid C++ like the plague anyway. If you DO pick up C++, avoid the STL containers like the plague - their performance is absolutely abyssmal.

Which containers and on what platform? Do you have data to support this conclusion available to show us?

Google "C++ STL performance" and you'll be inundated with people complaining about the performance, with no indication that it is relative to any one compiler or implementation. std::map and std::vector are particularly troublesome offenders. Compared to their counterparts in Boost, or their dynamic contemporaries in languages like Python, their performance is garbage until you start cranking up the compiler optimizations (which make the code arguably more difficult to debug.)

I have some example numbers on a (very narrow set of use cases) in a thing I've been putting together to illustrate these issues, actually.

https://github.com/akesterson/perftests/tree/master/countstrings

https://github.com/akesterson/perftests/tree/master/countints

Those two test cases illustrate C (with glib & hash maps) vs C++ (std::map and std::unordered_map) vs Python vs JavaScript vs Bash, comparing their relative execution speed to count the occurence of an item in a list of items (strings and ints), to illustrate the speed of each implementation's containers in setting, looking up, and checking for the existence of keys.

You CAN get C++ STL containers to perform admirably (see the -O2 settings on the documentation), but out of the box, the containers perform incredibly badly.

Why wouldn't you use full optimisation for a release build? Of course you're going to use -O2... and looking at performance in a debug build is just meaningless... debug builds are for stepping through code and debugging it...

That's not a debug build, that's just unoptimized. Debug builds include stabs, extra nametable info, etc, none of which the -O0 builds include. -O0 just means that there is no optimization performed by the compiler - how your code is written, is how it will run.

Yes, you will make a production build at -O2 or potentially even higher, and when you do that, you'll get near-C levels of performance. But that's not the point. The point is that the containers perform terribly until the compiler gets its hands on them and optimizes them; why? There's no obvious reason for it, not when C and glib are smoking it by orders of magnitude. RTTI and dynamic dispatch can't account for all of the slowness there - the C++ STL containers just aren't written for performance from the get-go.

Just realized we're jacking OP's thread, can make a separate thread re: STL performance if we want to keep talking about this.