Maybe it's because I've only been using C++ for about 2 years now (and probably because I've never really studied any other language as deeply as C++), but I really don't see what the big deal is with C++ it's just something you gotta learn. In my opinion you should start with C and evolve to C++ (atleast that's what I did and I haven't regretted it so far), after you have a good understanding of both start developing basic console games (like tic-tac-toe) and after your skills have grown try making simple 2D games (with programs like Game Editor or libraries like SDL) or if you're feeling really adventurous go straight to basic 3D games (again, with the help of programs and libraries); obviously you wont produce any commercial, mind-blowing games, but you will absorb a lot of knowledge about programming.

You've only used it for two years? That's really barely enough time to get to know the language. C++ is a huge and horrible beast of a language, with lots and lots and lots of lovely corner cases just waiting to bite you. That's not to say one can't start with it, but its a bad idea. You never have to learn C++ unless you decide to become a professional game developer. If you work indie, XNA, mobile phones, or similar, you can avoid C++ for almost the entire time. C is only slightly better than C++, having fewer of the more tricky corner cases, while still having plenty of lovely undefined behavior just waiting under the hood. I'm not trying to be mean, but even after 20 YEARS of using C++, I still find nasty corner cases that introduce fun. C++11 certainly didn't help in that regard.

Basically all I'm saying is to jump into the difficult stuff (cause your gonna have to learn it eventually), cry for a few days because you don't understand it (not literally),[/quote]

More like a few months, and even then you probably still won't understand the exact reasons why certain things are or are not valid.

There is a reason we recommend managed languages (like Java, C# and python) to beginners: Your goal, as a beginner, is to learn the art of programming. This is not something that is bound to a single language, it is a method of thinking, a set of paradigms, and the problem solving skills required to take a problem and produce a solution. As such, the language you choose to learn on your initial forays into the field should be one that encourages learning, provides results quickly, and does not require you to understand low level concepts before you can implement high level ideas. You will eventually learn lower level concepts, and you will eventually move on to other languages, many other languages. Each language has problems it is good at solving, and problems that it is terrible at solving. Eventually, when you have a tool chest of languages and paradigms you will find problem solving to not just be significantly simpler, but also significantly cleaner.

[quote name='MichaBen' timestamp='1332273676' post='4923725']
[quote name='Cornstalks' timestamp='1332211164' post='4923504']
C++'s syntax is just... tedious, especially for a beginner, and even more so when the compiler gives very non-beginner-friendly error/warning messages. That's the main issue with C++'s syntax and beginners.

You must be using a really crappy compiler then, mine simple says:
"Main.cpp:54: error: 'class std::vector<std::basic_string<char> >' has no member named 'begiin'"

And as for missing a semicolumn in a header:
"Component.h:25: error: expected ';' at end of member declaration"
[/quote]
If you consider g++ a crappy compiler then... sure, I guess I am. But that's even another issue: different compilers give different errors, and inconsistency is a disservice to beginners.
[/quote]
Yup. They don't even seem to agree on the simplest of errors as the following shows:
C:\Temp>type meow.cpp
#include <iostream>
using namespace std;
int main() {
cout < "Hello, world!";
}
C:\Temp>cl /EHsc /nologo /W4 meow.cpp
meow.cpp
meow.cpp(5) : warning C4130: '<' : logical operation on address of string constant
meow.cpp(5) : warning C4552: '<' : operator has no effect; expected operator with side-effect

This is actually required to compile by C++98/03, as cout has operator void *(). Comeau 4.3.10.1 also accepts this.

GCC 4.4.1 emits hard errors but I don't know what they're doing.

In C++0x, this should fail to compile due to changes in the Core Language and Standard Library. (While VC10 implements portions of C++0x, it doesn't implement the relevant changes here.)

- Stephan T. Lavavej

But I guess I can provide my own point of view:
[/quote]
This is For Beginners. Try to stick with facts, rather than opinions.

Just to quickly refute some of your points:

C++ is hardest out of those 3 because it has memory management, pointers and other weird stuff, however it has high performance because it's not virtual machine like Java, and doesn't require dynamic linking for everything like in C#. Therefore it's best suited for demanding applications (database, AAA games, simulations, etc).
[/quote]
Virtual machines have nothing to do with performance, nor does dynamic linking. The fact that current implementations of these might incur performance overhead is not a particularly interesting argument.

Consider virtual machines, if you look back a few years and see the performance difference between what they were then and where they are now - you will see that most of the "performance issues" are actually implementation issues. In addition, language implementations that have some kind of hypervisor/compiler functionality have lots of opportunities for advanced optimisation that we're only scratching the surface of (e.g. V8 javascript engine compiling dynamic function calls to inline assembler - no current C++ compiler can do this).

As for dynamic linking performance, I imagine any performance issues are most likely related to Microsoft attempting to keep backwards compatibility with their existing DLL systems. I've never looked into C#'s dynamic linking, so I cannot comment for certain, but if you were free to design a new dynamic link system from scratch, I see no reason one would have to pay a heavy runtime price for it. Indeed, again the nature of these languages could serve as a benefit, the abstract instructions here could be fully inlined into the caller when they are dynamically linked (possibly but considerably more difficult for fully native code).

Java is very cross-platform therefore is best suited for applications that target wide audience, however it's quite big letdown when it comes to performance. Huge amount of packages allows rapid development as well, but inability to create overloaded pointers can make game development complicated because of heavy math involvement.
[/quote]
Overloaded pointers?

Java's main performance pitfall is the memory structure - it suffers because it doesn't allow explicit value objects and AFAIK little or no memory layout optimisations are done automatically. This is where 95%+ of modern performance issues are - memory layout problems causing the busy loops to fall outside the cache.

Also I don't consider Java and C# true programming languages because they cannot run on machine without OS/extra libraries, like Assembly/C/C++ can...
[/quote]
Standard C++ and C cannot run on their own without an OS. Arguably, no program can run without an OS, without also being an OS.

In any case, C and C++ operate in their own kind of "virtual machine", just one that happens to map more or less directly to hardware very often. This abstraction insulates you from the processor just enough that you would need some assembly or language extensions to bootstrap you and/or to accomplish certain tasks.

And of course if you allow C or C++ that, then surely you must allow Java, C# or even Javascript the same, and you are back to where you started.

However unless you are in the business of writing operating systems I don't see any relevance of this line of reasoning.

... therefore I consider both of them to be scripting languages.
[/quote]
Arbitrary, line in the sand nonsense. The classification of a programming language as a "scripting language" (the latter usually considered a subset of the former, not a disjoin set), even under a definition of scripting language as unusual as yours (typically scripting language is more or less synonymous with dynamic typing), is irrelevant.