Do you need to make programs or games, like, right now, as in, immediately?

Yes -> C#

No -> C# or C++, doesn't matter.

C++ : A Cautionary Tale.

The past couple of days at work I've been working on optimisating/vectorising some C++ code - something I'm in fact normally very very good at (low level stuff is a kind of speciality of mine). Last week was a long one (~52h, or close to 7 days worth of hours in 5 days) due to us being in the closing weeks of the project so I was a little tired and thus didn't check the code in as I wanted to test it when I was fresh.

I tested the code, worked on two platforms but the rewritten SPU code didn't do as expected.
The code compiled - the code ran - but the code clearly wasn't correct.

Many hours of debugging later I discovered the two problems;
1. a difference in the API for SPU/PS3 vs PC/XBox
2. I'd made a mistake with some pointers.

Basically when I started writing the code on the friday I started with float*, so all my sizes, offsets and pointers were in terms of floats.

Later, however, I swapped to a vector format, 4 floats wide, but in my tiredness failed to update all my pointer offsets correctly.

The compiler accepted the code.
The SPU ran the code.
The code even produced some output without crashing for a good while.
But the code was wrong.

This is the kind of thing you get to work with when it comes to C++ : you might not be working with SPUs but it is oh so easy to make mistakes which function correctly 999 out of 1000 and then on the 1000s try blow up in your face.

An older tail, from a good 8 or 9 years back - I was working with a friend on some rendering concepts for a game. Code ran fine on my PC, didn't work properly on his. About a day later I finally found out why; an uninitialised variable. On my machine it would always spin up as 'true', on my friends it seemed to be 'false' 99% of the time.

When learning to program you don't want something which trips you up like this causing random and hard to explain bugs. I'm an experianced programmer and, despite the tale above, very good at it but even I trip up from time to time (I also write code which functions flawlessly as well, but that doesn't make for a good cautionary tale *chuckles*).

Reasons such as this are why C# and Python are recommended - they let you learn to reason as a programmer BEFORE you have to deal with the subtle and hard to find issues that C++ brings to the table.

And it's not like starting with a language which shields you from the crazy makes you any worse off in the long run; I started with BASIC and was happy there for many years before taking the leap into 68000 Assembly but at that point I had a strong understanding of programming which meant the assembly was easier to follow and understand.

Another thing, does developing in c++ really takes THAT much more time?? I mean let's say i was making a game in sfml and it took me 1 year. How much time do you think it would take me in c# and XNA?

Another thing, does developing in c++ really takes THAT much more time??

No it doesn't, comments like that usually are made by trolls who attempt to start a language flame war, it's best to not feed those trolls.

First of all, you should make a difference between language and framework. In almost every flamewar somebody comes up with the "GUI application with C++" example, when actually showing win32 window creation code written in C. Comparing two languages by comparing two GUI libraries, it's like comparing a highway with a dirtroad by looking at two random cars that happen to drive on those roads at a particular moment: complete nonsense. In fact, based on this kind of argument, I can easily prove that C++ programming is faster then C++ programming, which doesn't really make sense. The truth here is that the framework or engine is of major influence on the development speed of your application. Of course the language is of influence on how the easy the framework can be, as these frameworks rely on the features the language has to offer.

It's true that C++ has lots of ways to screw up then, and some of those are hard to debug. However in reality these bugs are only a minor part of all bugs, and the majority of the bugs are logic errors that will not be different in other languages. In fact one of my old C++ projects I made when still learning the language only has one known crash, which ironically happens on a smart pointer rather then a raw pointer, the other bugs are all logic errors. And some logic errors can be just as hard to debug as pointer errors, in fact at one point it took me around 10 hours to track down one incorrect if-condition that was causing an object that was explicitly marked as invisible to suddenly being rendered 20 minutes into the game. This can happen in any language, even if you would have a language that has validation logic for every variable you want to set and test it against the class invariant, as you can still describe the invariant incorrect.

As long as the developers are experienced with the chosen language, it will not make a lot of difference in development time. With raw memory management languages as C++ you may have some additional bugs to fix involving memory leaks and dangling pointers, but languages with garbage collectors have their own kind of bugs to deal with, as it's definitely not the case that garbage collectors take away the whole trouble of handling pointers nicely. If you don't design your classes properly, garbage collectors can easily break your class invariant and trigger undefined behaviour of your application.

So in the end, programming isn't easy at all. If you as a beginner are thinking of the choice between a language with raw memory management or a garbage collector, you forgot the third option: a language without any memory management. There is no need to use "new" in your first application, there is no need to start making classes when you don't know what a for-loop is yet, and there is no need to make an MMORPG if you don't know how an array works.