22 replies to this topic

[igna92ts]

How much harder is c++? because i was considering learning one or the other and I really don't have much time in my hands and i hear that c#and , for example , XNA are way faster to develop than c++ and ,say, sfml.
PS: I dont care about portability

[Kheyas]

Why don't you search through the forum first. Or even google... Yes, it is faster to learn C# and XNA. You can probably get to making simple games in less than 2 weeks?

[superman3275]

I can't tell if this is a troll or someone who just woke up and decided to make a game. C# is a less complex language, however I wouldn't consider it harder. And there are more than 3 threads about this same thing on the first page of the beginners section.

[timothyjlaird]

Figure it out for yourself...

Take some time and install VS2010 Express for c# and c++...all the tools that you need at this point are free. Make your goal drawing a single triangle in a window. First complete the task in c#, then in C++. Leverage the XNA (c#) and DirectX (c++) APIs/toolkits to do the drawing. Tutorials for this sort of thing are spammed all over the place. Just do some research with Google.

Get that far and you be able to ask much more specific, intelligent questions on which language and api/toolkit to learn more about.

Edited by timothyjlaird, 16 September 2012 - 01:29 PM.

[jbadams]

Any language will initially be difficult for a beginner -- but yes, C#/XNA is generally considered to be a bit easier and more approachable than C++ and SFML/SDL/Allegro, unless you're already an experienced C++ programmer.


Do you have any prior programming experience, even if you think it might not be relevant to games?

What exactly do you mean when you say you don't have much time available? Do you mean you don't have much time each day, or do you mean you have a deadline (6 months to complete a game for an assignment for example?) you need to meet? If you only have a little time each day and are trying to be productive then any language you're comfortable with should be fine, but if you have a fixed deadline you might want to consider easier options than C# or C++ to help ensure your success.


I agree with the above response: trying both languages out for yourself and making a more informed opinion based on your own personal preferences is an excellent idea. Although C# is generally considered easier and faster to develop with, some people absolutely swear by C++ instead, and you may well be one of those people.

You might also consider the amount and quality of reference materials available: for each language, think up a couple of topics you think you'll need to look up/learn about, and try to find resources for each language. Take note of how much material is available for each language, and check the quality of some of them is suitable.


Hope that helps!

[ATC]

I say just go ahead and learn C#. It's an essential skill for modern Windows programming to know C# (or at least some .NET language) and how to use the .NET Framework. C# will be much less painful to learn and you will be a deadly programmer when you learn it. Moving on to learning C and C++ will be FAR easier, as you will already understand programming and the languages are very similar in style, syntax and structure. But, in the end, you will need to know both to be a really effective game programmer and be eligible for a wide variety of jobs in the games industry... I just think learning C# first will be much easier.

Don't fall into the trap of thinking language A is "better" than language B. Most such claims are complete nonsense, unless we're saying BASIC and VB.NET sucks (just kidding! lol). Programming languages also do not (I repeat, do NOT) have any attribute, element or property called "power". All Turing-complete languages are "powerful". Theoretically, any Turing-complete language can calculate the entire span of existence of the known universe. C# is not "less powerful" than C or C++, nor is the reverse true. Likewise, assembly language is not more "powerful" than C... Languages also do not have any sort of fixed performance. The performance/speed of code varies from machine to machine, API to API, programmer to programmer, etc... Some languages can be theoretically faster than others due to physical limitations or advantages (e.g., JIT compiling or interpretation), but no programming language has a "top speed". Well-written C# code can easily outrun badly-written native code, and vice-versa. Managed languages, despite being theoretically slower due to JIT compiling, can sometimes be superior in performance to native code considering the gains in memory efficiency, reduced bugs, cleaner and better-written code, etc. While I can usually squeeze a couple more milliseconds out of C than I can with C#, sometimes complex algorithms can be faster in C#. It really all depends... just, like I said, never subscribe to any belief that any language is necessarily "better", "faster" or "more powerful" that any other (provided we're talking about practical, Turing-complete languages...not brainfuck or anything impractical).

If you start with C#, then you'll have the opportunity to learn the essence of Windows application programming (via Winforms) and the essence of DirectX (via XNA Framework). Both of these are easy-to-use APIs that are quick and easy to get started with but provide very deep, far-reaching and low-level capabilities. There's no reason you can't write a big, bad multi-million dollar Windows application with C#, just like you can with C or C++! There are plenty of them out there! When you feel you have "outgrown" the XNA Framework, which is like to happen when you want to write next-gen games for Windows, XBox or other platforms, then move on to learning SlimDX (the C# wrapper for DirectX and all its related APIs) and OpenGL.

[JamesTheNumberless]

I say just go ahead and learn C#. It's an essential skill for modern Windows programming to know C# (or at least some .NET language) and how to use the .NET Framework. C# will be much less painful to learn and you will be a deadly programmer when you learn it. Moving on to learning C and C++ will be FAR easier, as you will already understand programming and the languages are very similar in style, syntax and structure. But, in the end, you will need to know both to be a really effective game programmer and be eligible for a wide variety of jobs in the games industry... I just think learning C# first will be much easier.

Don't fall into the trap of thinking language A is "better" than language B. Most such claims are complete nonsense, unless we're saying BASIC and VB.NET sucks (just kidding! lol). Programming languages also do not (I repeat, do NOT) have any attribute, element or property called "power". All Turing-complete languages are "powerful". Theoretically, any Turing-complete language can calculate the entire span of existence of the known universe. C# is not "less powerful" than C or C++, nor is the reverse true. Likewise, assembly language is not more "powerful" than C... Languages also do not have any sort of fixed performance. The performance/speed of code varies from machine to machine, API to API, programmer to programmer, etc... Some languages can be theoretically faster than others due to physical limitations or advantages (e.g., JIT compiling or interpretation), but no programming language has a "top speed". Well-written C# code can easily outrun badly-written native code, and vice-versa. Managed languages, despite being theoretically slower due to JIT compiling, can sometimes be superior in performance to native code considering the gains in memory efficiency, reduced bugs, cleaner and better-written code, etc. While I can usually squeeze a couple more milliseconds out of C than I can with C#, sometimes complex algorithms can be faster in C#. It really all depends... just, like I said, never subscribe to any belief that any language is necessarily "better", "faster" or "more powerful" that any other (provided we're talking about practical, Turing-complete languages...not brainfuck or anything impractical).

If you start with C#, then you'll have the opportunity to learn the essence of Windows application programming (via Winforms) and the essence of DirectX (via XNA Framework). Both of these are easy-to-use APIs that are quick and easy to get started with but provide very deep, far-reaching and low-level capabilities. There's no reason you can't write a big, bad multi-million dollar Windows application with C#, just like you can with C or C++! There are plenty of them out there! When you feel you have "outgrown" the XNA Framework, which is like to happen when you want to write next-gen games for Windows, XBox or other platforms, then move on to learning SlimDX (the C# wrapper for DirectX and all its related APIs) and OpenGL.

This should be required reading for everyone before posting on a [name of managed language x] vs C++ thread

[JamesTheNumberless]

I can't tell if this is a troll or someone who just woke up and decided to make a game. C# is a less complex language, however I wouldn't consider it harder. And there are more than 3 threads about this same thing on the first page of the beginners section.

nooooooooo, C# is a more complex language - it has much more in it than C++ and is growing all the time (even if half of what they add these days is confusing people about the best way to use it) But programs written in C++ are more complex out of the necessity of dealing with a lot of machine level concepts that are dealt with for you by the C# runtime. C# has features that are far beyond anything C++ by itself can comprehend such as support for dynamic typing, memory management and a completely different system of linking & compiling that's much faster, cleaner and more advanced. There's nothing stopping you from making all these things in C++, and there are low level things you can make C++ do that are unavailable in C# (without unsafe code or interop) but those are available by virtue of the language being simple, not complex

[chrispetersinc]

This is a really good question and a lot of people are asking it now that Microsoft has been completely silent about the future of the premier C# game programming framework, XNA. I wracked my brain for weeks a few months back on whether or not I should go C# or C++ for my future projects and I decided to stick with C#. I honestly haven't reached any computational limits with C# on rendering, collision detection, or animation yet that would warrant me going to C++. I probably will never go C++ at this point considering I don't have a team of programmers to even come close to creating a complex enough game to warrant the need for the level of tweaking that C++ gives you.

I guess if you actually plan on pursuing a career in game programming for a large studio then you might want to go C++... I think if you want to just making something cool and don't want to quit your day job doing it then go C#. Personal opinion though.

[Serapth]

C# is a more complex language, C++ is a more complicated one.

Take from that what you will.

[alnite]

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

Yes -> C#

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

[phantom]

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.

[Postie]

I used to be hooked on C, but since using C#, I appreciate the way the language stops me from making stupid mistakes.

[ATC]

@JamesTheNumberless: Thanks, I tried my best to put the point into words! :-)

@crispetersinc:

I ended up leaving XNA when 4.0 came out and deeply disappointed me... having turned away from the PC platform drastically in favor of XBox and mobile device programmers. Then there's the fact that XNA is just a wrapper and framework for DirectX, and it leaves you stuck, without any choice, with 32-bit apps/games and terribly outdated D3D9... D3D9 is over a decade old! So I finally figured why not use the best and most up-to-date DirectX technologies that will still be respectable in the next few years when I start finishing up and releasing software. If I started a big 4+ year long project with XNA then D3D9 would just be even more dated... who knows, it might end up being unsupported by graphics hardware and newer Windows OS's in several years and be a complete waste for anything beyond its legacy uses? That's why I migrated to SlimDX, and am hunting for a permanent OpenGL wrapper to use. I feel that a good, well-written C# game engine can do anything XNA can do but do it better, faster and more beautifully. XNA, after all, isn't even an engine...

[igna92ts]

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?

[Telastyn]

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

I've programmed in C++ for around a decade, C# for around 7 years now. Unless I'm doing work on buffers (or trivial work), I can complete the task in about an order of magnitude less time using C#, with an order of magnitude fewer bugs. YMMV.

So for me a C++ game in a year would take a month and half or so in C#. For beginners, I would expect that to be far worse due to added bugs introduced by not knowing C++ best practices.

[Serapth]

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

No. It probably takes even more.

[MichaBen]

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.

[Telastyn]

As long as the developers are experienced with the chosen language, it will not make a lot of difference in development time.

I call bullshit.

Here's a summary of two studies.
Another measuring productivity of languages across a sequence of developers.

I'm sure that google can find more beyond the first two links I picked...

[swiftcoder]

If you don't design your classes properly, garbage collectors can easily break your class invariant and trigger undefined behaviour of your application.

Wait, come again?

Garbage collectors collect garbage. Otherwise known as 'unreferenced objects'. Unless you have whimsical class invariants that require objects to which you do not hold a pointer to stay at fixed memory addresses, a garbage collector can't break your invariants. And such whimsy is impossible in a Java-style language, because you can't create pointer values from arbitrary memory addresses in the first place.