How much faster is c# at making games than c++?

Started by
83 comments, last by ShawMishrak 17 years, 10 months ago
for an good experienced developer the only benifit WRT developement time is C# doesnt need to be compiled this is offset somewhat by it having a slower startup time
Advertisement
Quote:Original post by zedzeek
for an good experienced developer the only benifit WRT developement time is C# doesnt need to be compiled this is offset somewhat by it having a slower startup time


C# does need to be compiled...
does it? sorry my mistake i misremembered a reply by someone else from a post i made
http://www.gamedev.net/community/forums/topic.asp?topic_id=317431
Quote:- Near instant compile time (and on-the-fly background compilation). No more waiting for a build to finish!

scrub my point then, then theres no development time advantage in a game for an experienced programmeur to use java/c#
I'm curious: of those who are claiming C# has no advantages in terms of dev time for experienced programmers, how many of you are actually truly experienced programmers? [smile]


C# is a far better choice. You have good access to low-level hardware capabilities via Managed DirectX, which is a very sweet library. Garbage collection is infinitely superior to manual memory management for all but a very few niche development situations; I know many experienced programmers (myself included) who are still prone to get manual memory management wrong. C# has a horde of high-level constructs like delegates that can produce much more concise, expressive code over C++. C# also has superior GUI implementation capabilities, even over the best C++ GUI tools (C++ Builder and VC++/MFC come to mind).

In addition to being a more expressive (and clean) language, C# has a far more robust library, which has the advantage of being entirely developed at once rather than being cobbled together over time (ala C++SL/STL/Boost). This means it is generally easier to achieve interoperability between different elements of the library and your own code.

C# also has the amazing advantage of not being tied to a hideously broken compilation model; things like side-by-side assemblies can make code reuse far more efficient over time. You also escape the temptation to do a lot of disgusting macro hackery, which, sad to say, even good experienced C++ programmers are prone to do every now and then.

.Net has other powerful abilities, like easy cross-language development. Write high-level code in IronPython or F# or whatever, and low-level stuff in C# or even C++/CLI. Use other .Net languages for runtime scripting. Do automatic plugin discovery with reflection. It's an incredibly potent platform, and C++ will never catch up.


As if all that weren't enough, C# is built on the .Net runtime, which has one huge powerful advantage: JIT compilation. Instead of having to build one binary and hoping it performs well on a huge array of processors and system builds, you can ship CLR code which is then JIT compiled and can actually become faster over time. Each person's individual system gets a machine binary that is as efficient as possible for their hardware configuration. As hardware continues to diverge, and as JIT technology continues to improve, the days of C++ being the king of performance will disappear very quickly.

In any case, it's a good idea to get away from C++ sooner rather than later. As multiprocessing continues to become more commonplace, and with increasing core-count processors on the horizon, C++ will quickly become obsolete. C++ has absolute crap support for synchronization and multiprocessing, and while efforts like OpenMP are trying hard to counteract that, it is inevitable that a better language will take over. That language probably won't be C# per se, but it's still a good idea to have more languages under your belt than C++. Being a one-trick-pony is not a good situation in the technology sector [smile]



So there you go. Use C#, or IronPython, or F#, or whatever you want. C++ is not the best choice. In fact, there's a good chance it isn't even a good choice.

Wielder of the Sacred Wands
[Work - ArenaNet] [Epoch Language] [Scribblings]

As for this comment: "As multiprocessing continues to become more commonplace, and with increasing core-count processors on the horizon, C++ will quickly become obsolete."

It's a good thing that the architect for C# is also the chairman of the C++ comittee. Here's the future of both C++ and .Net in terms of concurrency:
http://microsoft.sitestream.com/PDC05/TLN/TLN309_files/Default.htm#nopreload=1&autostart=1
Also, if you're a game programmer, particularly a console programmer, you probably don't have access to the .Net framework on your platform.
Quote:Original post by RDragon1
Also, if you're a game programmer, particularly a console programmer, you probably don't have access to the .Net framework on your platform.



Don't be too sure... [wink]

Besides, I doubt many console programmers are worrying about what language to write code in at the moment.


I couldn't get your link to load, but it sounds interesting. Any alternate places I could look to find out what you're referring to?

Wielder of the Sacred Wands
[Work - ArenaNet] [Epoch Language] [Scribblings]

You work for Microsoft or something?
Who, me?

No. I work here.

Wielder of the Sacred Wands
[Work - ArenaNet] [Epoch Language] [Scribblings]

Why is it always C# against C++

Why not consider Managed C++ if you are already a C++ programmer.
C# is by design a new language
Managed C++ is by design for those you already know C++.
So if you choose managed over unmanaged, there is no reason to consider C#. After all this is what the .Net framework is all about, single library and multiple languages (COMMON language runtime)
[ my blog ]

This topic is closed to new replies.

Advertisement