I can't think of a single STL container that uses RTTI or dynamic dispatch...

And I think you're going to struggle to write a decent container in C without using a ton of macros (void* is going to be slower than templates).

I also hear that Usain Bolt is slow if you tie bricks to his feet...

Yeah, but he's only slower than Usain Bolt w/o bricks tied to his feet :)

Almost everyone who posts on this forum will usually argue that it's best not to start with C++? But how will you know when it's time to move on to C++?

The reason I want to get into C++ is not because I think it's a superior language to Java(What I use now), I just feel that there are more C++ game programmers out there and it's easier to get support on my projects and more code samples to look at.

To address your questions I would say that there's going to be as much "general" support out there for C++ as there is for Java. They're both mature, well established languages with very large user bases.

As far as game development is concerned, if support and code samples are your concern, you probably want to focus more on specific game development libraries and frameworks rather than something as broad as a programming language. For example, I'd love to learn Monogame (which is based on C#), but I haven't yet. Sure, there's a ton of C# documentation and support out there, but not nearly as much for Monogame.

Finally, I think it's worth asking: What's your long term goal here? Are you a hobbyist or looking to work for a big development studio at some point?

Hope this helps!

@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.

While I will say for a programmer it would be important to know the concepts behind the containers in the STL, though to say to avoid them is stretching it by a good amount.

The chances of an average joe programmer to write containers that are more optimized in terms of speed and usability are more than likely very slim. An average programmer will more than likely not produce code anywhere near that of what the programmers of STL do. Hell even if they did, the chances of it being "safe" and "bug free" are even less slim.

Though I would say it wouldn't hurt to know the concepts behind the containers and implement your own version of them just for learning and learning only.

for containers, it depends some on what a person is doing as well.

from a performance POV, direct access to a C-style array is hard to beat:
Foo **arr;
...
obj=arr[idx];

but, if adding things like bounds-checking, insert operations, ... then without care, these costs can quickly add up (and overshadow any inherent speed advantage).

so, a person ends up needing to take into account things like when and where to insert checks, ... and for the most part uses raw array access.

meanwhile, many people swear by generic containers, and some others believe them to be overrated (like, they can be good and nice sometimes, but hardly a one-size-fits-all solution either).

others may come from a tradition where it is more common to write the logic for managing collections of a given type of object along with the object in question (where relevant each type of object supplies its own container), ...

so, it depends some.


it is sort of like floating point vs fixed point:
many will say floating point is fast enough for anything, faster than fixed-point on current hardware, ... basically, that a person should always choose floating point, and never consider the "ancient cruft" that is fixed-point arithmetic.

sometimes there are good reasons, like fixed point can be a pain to get right, tends to result in opaque-looking code, with funky issues like having to worry about things like value precision and overflow, ..., and if written naively (or used inappropriately) will in-fact generally be slower.
but, for some types of tasks, there are still cases where fixed point may significantly outperform floating point (*1), or offer special advantages (like being able to cram a value into a smaller number of bits), and, on the other side, cases where if fixed point is used it may lead to annoying arbitrary limitations and/or weird bugs.

*1: typically in image and signal processing tasks (such as in a video codec).

and, probably, if your "average joe" programmer tries to use fixed-point, they will mess it up.
yet, no reason for a person not to have the tool in their toolbox.

programming decisions need not always aim for the least-common-denominator.