C# Vs C++

In your opionion which language is better?

Lots of people tell me c++ is better but lots of people tell me c# is better.


I do realise that Unity doesn't have c++ in it so there may be more people voting for c# but I would still like to find out

 

As with every "x or y" question, it depends entirely on the context.

Something like a game engine is far more likely to be written in C++ whereas C# makes more sense from a game code perspective, ie Unity.

 

If you're going to make that statement, you should actually support it.

 

C# is much easier. A friend was teaching it to me. It is much like Unity's UnityScript. Except, for the variables, you don't put:
'var object : transform;' // You put this:
'public transform object;' // If it is private, you simply do not put public. You also use at the top 'using . . . . . . '


Ii like it.

 

C# is basically Java; (in fact, it's closer to Java than JavaScript, which is nothing like Java) it's a really nice OOP languages with a lot of features that make your life easier.

C++ is more like a weapon than a tool: it's really powerful, but if you don't know what you're doing you're going to cause a lot of damage to yourself and others. It allows you to access memory directly, and it has a lot of other language features (like multiple inheritance) that will blow up in your face if you're not extremely careful.

Lots of people will tell you that C++ is faster; that's only partially true. If you write the same algorithm in C++ or C#, the difference will be only trivially in favor of C++. To really exploit C#'s speed, you have to take advantage of C++'s control over the low-level systems of the computer beyond what C# can do.

Overall, though, the programmer's time is more valuable than the computer's time, and you really should pick whichever language gives you least headaches.

 

c# is less feature rich compared to c++, secondly C++ performs way better compared to C#.
(why have most engines c++ under the hood, and not c#? indeed, performance, scalabilities etc.)
C# is fine for "simple" purposes, not for real powerhouse work (like realtime complex rendering, and other performance dependent things)

C# is interpreted language (not compiled to machine code, it needs a runtime engine (VES): mono or .net runtime ), whereas c++ is native (compiled to machine code).
C# is in nature cross platform, just as Java is. (since the code is not machine code compiled, the runtime executing the code needs to do the dirty job).
C++ compiled code is platform specific (thus highly optimized for that platform, see above).

 

It's the other way around. C# is more feature rich compared to C++, which is relatively bare-bones.

In most cases C++ performs only somewhat better than C#.

C# isn't interpreted, it's compiled to intermediate code, which is JIT compiled. Except on mobile devices, where it's AOT compiled and thus fully native code.

--Eric

 

c# is miles better, what are you even smoking? to code in. It's a modern language.

c++ is freaking decades out of date, and not very much fun to code in.

Now lets phrase from better to most useful, then my replies change:

c# is very useful for game logic
c++ is very useful for game engines

 

As i've learned from professors in the programming field:

not really, with c# your are very much dependent on what functions etc are supported by the virtual machine (jit)(VES) in the framework (mono or .net).
With C++ you don't have this limitation in general.
(heck even .net was made with c++)

Not true. C# is slower by miles compared to C++ (again why are 90% of all top game engines build in c++ and not C#? think about that for a second or 10, and then come back)

intermidiate code is not native. JIT is a form of interpreting, in the way it converts the code to an action on runtime. (thus it interprets the bytecode application to a machine code on runtime, simply explained)
C++ doesn't need this conversion, it's already converted.

Yeah it's a modern language, but that doesn't make it better by definition.

So? it's a personal opinion what one likes more. Also (pre) knowlegde is key to your comment.
If a person learned one language all other language are strange in that persons eyes.
How old a language is is complete irrelevant, for it's functionality/use.

Yep, i said that already (c# for "simple" code, c++ for heavy duty code)

 

http://reverseblade.blogspot.com/2009/02/c-versus-c-versus-java-performance.html

This compares relative speeds of some routines. Notice that it says C++ is ~15% faster than .NET in the same routines and ~50% faster than Mono, but more importantly:

Obviously, this applies differently to Unity, but for the question then it should suffice.

 

use python, is a lot easier and is gaining every time more adepts.. actually the systems are enough fast to handle high level programming language.. i think if your are not going to do plugins, drivers or such things.. go for high level languages..

 

Well, that's a problem. You need to research real-world cases instead.

Yes really, by any standard at all, the C# language is more feature-rich than C++. C++ is more low-level. The point of high-level languages is that they have more features.

Nope, C++ is only significantly faster in certain specialized cases. See benchmarks.

In some cases, JIT code can actually be faster than native code, since it can take advantage of whatever runtime environment it's on, instead of relying on lowest-common-denominator code. And as I mentioned, C# can be AOT compiled too, so it's a moot point.

--Eric

 

Love the address for this page... C-Vs-C!

 

And has nothing to do with c++ being nearly 30 years old? I have news for you, most game engine's base technology is very old, they didn't have a choice to use c#, even if they understood it's benefits.

I've coded engine tech in c++ for many, many years. From a competitive standpoint, it'd be great for me if C++ were still the best solution for game development, but it largely is not. C# is better if you're interested in actually getting things done. C++ is better if you don't know any better.

The performance benefit of c++ is there, for sure, but it's silly to consider it as a pivotal factor. In the wild, vast majority of your code speed simply does not matter. Even if it resulted in a real-world speed increase of 50%, which it likely will not, your code will still not likely reach the 20% of overall CPU time spent, so getting a 10% speed increase (which will likely not be a true limiting factor, considering most platforms are multi-core) is sooooo not worth what you lose. I've yet to see a gamer say "I'd have liked the game if it were only 10% faster", but I've heard countless times "I didn't like it, it was buggy" or "...lacked features", two things directly related to how fast the language is to develop in and how error prone it is, and C# is wildly superior to C++ in these regards.

Modern optomization is more a matter of knowing how to work APIs/hardware, generating smooth concurrency, avoiding cache hits, that sort of thing. Pure algorithm comparisons don't take that into consideration, generally.

 

C#

Hands down

 

the first computer language I learned was C, then I came across C++, and I thought: 'what is all this crap for?' it makes C slower, cumbersome and multiplies errors in unbelievable ways... no thanks, i'll stick to C... then I stopped programming and went and did some more social things with my life...

now I'm back to coding with unityscript... I think I might move to C# in the near future too... I can't believe the ease of use, and I can only guess how much faster things could be if they were made in C, but to be honest... I can also see how large the code would be... trading some things for others I guess...

 

Objective-C!


(hides)

 

A lot of the performance of any language lies with the effectiveness of the programmer. I'd say my ability to keep track of what's going on in some of the more complex logic routines is greatly enhanced by using C#, compared to C++. Thus, C# makes it easier for me to optimise, restructure and generally make better at least 85% of my code, if not more.

 

I don't know? Is it because Unity is used by over 150 THOUSAND active developers representing 1 MN hours of dev each month, has over 60MN web plugin installs and runs in extremely performance limited situations (Integrated graphics, Pentium processor, iPhone, Android).

It doesn't have to be 'miles' faster, just a 'little bit' faster.

 

the days that C++ was worlds faster were quite some time ago.
its still faster yeah, but the difference is not worlds and its not the reason why engiens are in C++

the reason why engines are in C++ is that c++ offers dirty lowlevel tricks that allow you to do things that are not needfully safe and naturally cause most middleware you implement in the engine exists for C++ only forcing you to be on C / C++ too to work performantly with it

 

Learn them both. Then choose the right one for the job. I've been programming for more years than many of you have been alive, I have written two different and complete 3D engines that have been used in commercial games in C++.
But let me tell you - I normally use C#, because it is faster to code in, and much harder to make bugs. And easier to debug when you do. I will now only code in C++ when required.

 

Err.. You realize the C and C++ are almost virtually the same... the only real difference is its OO nature... C++ is technically not an entirely different language from C... more of an increment.. hence the name. If your finding C++ that much more challenging than C, then it's not the programming language you should be dissing... it's the OO paradigm... With that said, OOP is has become the norm with any programming project these days, whether it be a video game, or a simple application... about the only time OOP is not really *needed* is with consol applications, and even then, most of them can benefit heavily from OOP design patterns.

Furthermore, There is NOTHING in C++ that makes it any slower than C... it's the same language, just with added features. If you are experiencing slowdowns due to C++, then you are simply doing something wrong...

 

C++ is used to make game engines because it's easier to port it to most hardwares available to play games. You just have to implement what you need and not all the features plataforms like Java or .NET require you to code to have things running.

 

Actually this is not correct. First off, C compiles very differently than C++, C++ code is not compatible with C, and on some compilers C code may not be compatible with C++. As well as C++ has many features that if used will slow you down. If you use purely C features of C++ it will be just as fast as C (depending on the compiler), but at that point, whats the point.

C++ was an attempt to make C OO, however, in my own opinion, its very ugly code. C# is like a mix between Java and C++ only more convoluted, less powerful, and controlled fully by microsoft.

 

This.

When Criterion built Renderware 3 way back in 2000 — the first 3D graphics middleware to see major success in the games industry — it was written in C, with some OOP-ish design patterns to make it easier for customers to extend. Why did they use C? Because, when a console manufacturer releases their baby, their development tools, particularly on release, tend to suck. A lot. And the C compiler is usually the first component to become truly stable.

Back then, consoles came with very little in the way of developer support. Microsoft's Xbox series broke new ground by including support for decent development toolchains and the like. (The Xbox360 even supports .NET-derived tools, including C#.)

C++ is now the baseline standard for consoles as the development tools are effectively a given: once you've written a PowerPC compiler, you don't then need to rewrite it from scratch just for the next release. (The Sony PS3 had trouble gaining traction initially precisely because its architecture was so different: Sony needed more time to finesse their development tools.)

In other words, Unity is only built in C++ because it has to be. Not because it's a great language. (Pretty much any professional programmer will tell you C++'s design-by-committee approach has resulted in an absolute camel of a language, "known" by many, but truly mastered by only a very, very, few.)

If raw speed really is your holy grail, then C is by far the better choice as it is far closer to how a typical CPU works than C++ (unless CPUs that understand OOP at the silicon level are all around us and nobody bothered to send me, or anyone else, the memo). On top of which, you'll probably want to buy some books on assembly language for each of your target CPUs, as well as the relevant technical and performance specs from each CPU manufacturer.

*

Language comparison threads like these are generally worthless. Programming languages are tools. Nothing more. Use the right tool for the job. Part of learning to program is learning what each of the tools available can do, what their pros and cons are, etc. A programmer who only knows one programming language will have a very limited view of what programming is truly all about.

High-level FSM management code for a Unity project should be written in a suitable, high-level, language, not C, or assembly language. Similarly, mission-critical software, such as an aircraft management system for an airliner or fighter jet, would usually be written in a language like SparkAda, not Visual Basic 6.

Someone new to programming will be better off with a development environment that's easier to get immediate results with, and which lends itself well to learning. Unity is one such platform: you can see the results of your efforts very quickly and easily.

Starting with C++, on the other hand, is like learning to drive in a Chieftain tank.

 

Everyone seems to be forgetting that a programming language is just a syntax. Everything else are just libraries, APIs, SDKs, Frameworks, etc... For example, cstdlib, and stdlib. One is C, one is C++. Both do things very differently, but when it comes down to it, the only real difference is one takes advantage of OO, while the other doesn't (OK, so each has a different set of tools, but I am talking about the design).

another classic example:

reading a file:

In C, you would use a FILE pointer (FILE*) which is a type (or possibly a macro... never really looked into it) defined in the cstdlib header.
you would then proceed to use a collection of methods including fopen() fread(), etc... and their variants to work with the file.

In C++, you simply create a stream object, such as ifstream or ofstream, that are defined in the fstream header and use the classes methods such as get(), getline(), put(), etc... to handle the file input/output.

Both do the same thing in the end, but both do things entirely differently.

Sure, they are compiled differently, but that's to be expected when you do the same thing two different ways.

Perhaps the C++ methods are a bit less efficient, but that's why you are allowed to use C functions and types in a C++ program... the syntax is the same, only with C++ adding more OO stuff.

 

Not quite correct, they compile very differently, C++ takes autonomous advantage of exceptions where as C doesn't, C++ has some very high level type features which can make the runtime slow. C doesn't really have a runtime. It jumps to main basically. C++ does have a runtime though.

A language is defined not only by its syntax but by its method of compilation and runtime.

- The systems level developer who develops languages for his system because he's awesome like that.

 

C# wins hands down

 

C++ is a language over 20 years old.
Sure it gives you finer control over a few things but C# is definately the way forward, and a language of the future.

 

You are all wrong we should all use AMOS, nothing beat it )

 

Comparing c# and c++ is like comparing guns and knives. Each has its place.
A gun may win hands down in open field combat but won't help you at all when it comes to slicing bread.

A test I ran recently on my PC to see the comparitive speed of a simple operation, by doing i++ 1 billion times:
c# took 2.5 seconds, delphi took 0.4 seconds. c++ will also do it in 0.4 seconds.
c# is managed code and thus has a lot of overhead and basic requirements. Unity would probably be 30% slower with 100% extra memory overhead it it was written in c#

There are some things that aren't even possible in c# as you don't have much access to hardware.
The software you're using right now - your browser, unity, photoshop, windows etc were all written in c++, so even if it's old, it will not be replaced for a long time. I'm not so sure about c# though. It's only around until they discover something easier.

The real question is, which do you prefer?

 

C# took me ~ 420 ms. On a single core. Q6600.

http://pastebin.com/XTg74cw6

Console Application. press ctrl-f5 to test.

C# ain't the fast language ever invented, but it is not that slow.

The theory is that with the time saved I can make it faster. So here is a .net 4.0 (not unity ) speedup:

http://pastebin.com/ESG4SLX0

I get up to a 4x speed up, though it varies quite a bit.

 

NPSF3000
Your code is simply a loop which executes 1 billion times, not an increment within a loop
I used
for (int j=0; j < 1000000000; j++) {
i++;
}
then subtracted the time of a blank look from the results.

The problem is that in managed code produced the following assembly:
mov eax,dword ptr [rsp+30h]
add eax,1
mov dword ptr [rsp+30h],eax

whereas delphi and c++ produce the following
inc eax

That's a huge difference. Non-managed compilers can optimize use of registers where as managed code seems to always fetch from memory and store it back each time.
Your threaded example will probably slow down quite a bit when using a variable because it will all use the same memory reference and if the instruction were a little more complicated than just i++ the threads would conflict.

 

Hey, all you gave me was:

And that is all I did. It's not my fault if you did it slowly. If you said you where testing the performance of a for loop then that's something entirely different.

And while using a for loop like you did does slow it down, you don't have to use a for loop.

Code (csharp):

1.  
2. while (sum < 1000000000)
3. {
4.    sum++;
5. }
6.  

Also gives me a result around 420ms. (Again, down to 108ms threaded).

If you think this won't work in a non-trivial situation, then actually try a non-trivial application.

 

This is a question so fruitless its borderline trolling, though I'm sure the OP had honest intentions.

What language you're going to pick is going to *entirely* depend on the situation.

I'll tell you this though, almost every game engine out there relies on an interpreted language to actually run gameplay code. From the biggest AAA games on the market, interpreted languages are the tools used to design gameplay; and for a good reason.

You don't want to recompile half your game every time you change something.
You don't want your scripts to crash your game engine.
You don't want your scripts to have access to low level code and screw something up.

If your intention is to write logic and design game play, forget C++.

If your intention is to write a rendering engine, forget C#.

 

touche.
My conclusion:
It's not the language, it's how well you use it.
And as far as unity goes, you'll get more benefit optimising your code then you will get with the hassle of implementing it in c++ via dlls or plugins.
When it comes to interfacing with hardware, you'll probably need c++ though.

 

Thanks.

My conclusion: Experimenting is good. By alerting me to the fact there was a performance issue, I managed a very significant speed-up (up to 27x if threading counts). Of course, if anyone does actually want to count to a billion:

i = 1000000000;

Is very fast

I do respect that you tried to find the issue, even if you stopped short of fixing it.

 

How? By counting off every commercial game engine that was written in C++ compared to the ones that weren't made in C#?

I love C#. I bought Visual C# when it first came out and have been using it ever since, but I'm under no illusions that it in in some way "better" than C++. Besides, "better" is 100% subjective. Why not use a more objective word like "powerful?" I think glaze donuts are better than C# because they're delicious in my belly whereas C# makes my eyes hurt.

By real-world, do you mean today or ten years ago? Ten years ago C++ was ridiculously faster than C# because the hardware wasn't there. Nowadays C++ is still ridiculously faster than C#, only you can't tell so much because the hardware is much, much faster. So yes, C++ is still much faster than C#, you don't notice it so much in the kinds of apps people use C# for. Now, start using it for more intensive apps like CAD, Design, Game Engines, Physics and you see why those are done in C++. Come on, guys, why do we have this debate every year?

 

Did I really see arguments against C++ because its old? Are you guys serious? Thats about the same as saying "Bread is so out because its thousands of years old." The language depends on the task and the skill of the engineer. I personally prefer C++, because of the extensive use of pointers (and because its the first language I learned). Much more efficient than having to copy variables and object instances over and over again.

 

Real programmer will immediately fell in love with C/C++, because of it being low level, and it is a freaking beast and freaking fast. Direct manipulation of pointer is so soothing to his heart - no kidding. Among John Carmac's quote is 'low level programming gives soul to programmer' - something like that.

But in the real world, one has to be practical. C++ has its places and C# has it too, sometimes they are in conflict - world editor anyone? But if you are creating a game engine, C/C++ is the way. C# can be the wrapper so that the user of your game engine can run the game without waiting for the slow compilation and linking process. C# is not suitable for game engine because:-
1) it is not as fast as C++.
2) C# has the garbage collector running in background - can somehow stall a little of the CPU, very difficult to control when the garbage collector kicks in. You must have COMPLETE control and if possible, you must have source code for everything.
3) All those .NET runtime is just kind of mess. I have not had much experience with .NET, but .NET distribution installs all kind of DLLs/whatnots into so many places, and I dont have a control on it.

 

It's rarely a good idea to expound upon a subject from a position of ignorance.

 

Heh, I must not be a "real" programmer than, because I'm clearly not in love with C++. I guess the super ultra real programmers love assembly? And don't even get me started on byte code! What real programmer doesn't want to type out platform-specific 010010100001010001 code?

Ridiculous statement. As to your other 3 points, I'll break them down for you.

1) You're probably right. But luckily, the vast majority of the actual work is actually being done by Unity or on the GPU.

2) Misinformation. You can have complete control of garbage by smartly recycling objects, allocating on the stack instead of the heap and generally being smart about how you allocate. You must have source code for everything? What? You have the source code for DirectX??

3) You do realize you us the SAME $!#* DLLs in C++ too. Right? If you're programming on windows, you're likely going to be using DirectX DLLs. You know how many different versions of DirectX there are? You don't have control over $#!t.

 

In reply to the original poster's question, "C# vs. C++" is like asking "Hammer vs. Saw".

 

I've seen this conversation somewhere before....

http://forum.unity3d.com/threads/40360-Why-is-c-bad-for-games-dev

 

andorov , I don't have much knowledge on .NET CLR, but out of curiosity how do you control memory allocation in .NET? I mean how can you force the memory allocation at the stack instead of whatever memory allocation control CLR uses. Also, again without any deep knowledge, but how can you recycle an object, or tell the GC that said object is not usable anymore? ( I know they use scopes within, so the GC can decide wheter or not it is accesible, and thus usable, but the question is how you tell him such a thing ).

 

All structs are allocated on the stack, and all classes are allocated on the heap (garbage collector). So, if you're going to be creating and destroying lots of different small classes, consider converting them to structs. Note that structs that cause new classes to be created (via the NEW call are still causing allocations).

The other big thing is object pooling. Don't needlessly destroy your prefabs or classes if you can simply recycle them. For example, if I even have the inkling that a class will be created over and over again, i build in a simple "reset" constructor that I can call to reset the class. This can be more complicated in some cases than others. I think create a pool to hold all my allocations and simply reuse the object.

String operations are also a big no no. For most games, string operations are what will cause a massive amount of allocations, for example.
String str = "hi";
str += "1";
str += "2";
str += "3";

will actually allocate "hi", "hi1", "hi12", "hi123" which will cause 14B of garbage. Do that every frame multiple time, and you've screwed yourself.

Theres lots of little tips and tricks to keep allocations low, but I don't think this is the thread to discuss that

 

^ This.

The two things I miss most when moving to a managed language are direct access to memory and control over garbage collection. Oh how I miss linked lists of structs. Box this biatch! It's as if the designers of C# thought that random access inserts and deletes weren't needed anymore. Though, the speed of computers these days sort of puts heavy makeup on such warts.

In the end, judging from the "can u give me my codez 2 type plz" posts that swamp the scripting forum...can you really imagine such people dealing with pointers? If they have issues understanding they need match their bras to their kets, can you imagine them trying to make sure their malloc's are free'd?

While I miss having low level access, C# makes a far better language for something such as Unity.

 

I'm going to pick on you.

Can I just say, from my position of 'ignorance' that this is the biggest load of horsesh*t I've ever heard? And I keep on hearing it!

Pure performance is not the be and end all! (However a sexy beast she may be, with all her 'pointers').

Must I remind you all that EVE online runs on python?

 

C# wasn't designed to be a replacement for C/C++ or perform better or even compete with them.
Most software in existence spends nearly all it's clock cycles time waiting for user input. Someone using one finger to type in Office isn't going to need the software performance of a real time cruise missile system or 3d engine

Like has been said, different tools for different jobs.

 

EVE logic runs on python, the engine runs on C/C++.

It's not as fast as C++. You can't preform a loop and presume that it is just as fast, faster, or slower from the results of that overly simple test. While performance is not the most important thing, it is quite important.