Jump to content

  • Log In with Google      Sign In   
  • Create Account

14 years ago on June 15th Gamedev.net was first launched! We want to thank all of you for being part of our community and hope the best years are ahead of us. Happy birthday Gamedev.net!

#Actualbeans222

Posted 26 December 2012 - 11:25 PM

C++ operates at a lower level of abstraction than C#. In C++, you could (if you wanted to) trivially fill an array with machine code, cast it to a function and run that code (it would no longer have any amount of portability at that point).

C# compiles to a bytecode that wasn't the machine code of any processor (I say 'wasn't' because I haven't followed C# in a while; they may have built one since). C# programs are run by what is often called an interpreter even though C# runtime has always compiled to machine code on the fly. In a C++ program, the progammer has manual access to freeing memory (as well as the pointers to/within it). A C# program uses the garbage collector to take care of freeing memory (as in, C# doesn't have a 'delete' operator, just 'new').

 

Some people might even argue that C# could be faster because C# gets compiled on the fly, the runtime knows exactly what the best actual machine instructions are for the users exact hardware (as opposed to a C++ compiler having to target some lower denominator of CPU like no-SSE, unless you actually provide multiple binaries for users to choose from or users compile themselves).

 

The fact that a C++ process will never slow down, use an extra thread (or *gasp* pause) for a garbage collection is probably one of the best reasons for people who like control. I thought was going to come up with better arguments, but other than memory access and allocation, it's late and I'm drawing a blank. The runtime compiling C# bytecode on the fly takes time too, and I imagine there's a threshold of how many interprets of the function before it decides to compile.


#1beans222

Posted 26 December 2012 - 11:21 PM

C++ operates at a lower level of abstraction than C#. In C++, you could (if you wanted to) trivially fill an array with machine code, cast it to a function and run that code (it would no longer have any amount of portability at that point).

C# compiles to a bytecode that wasn't the machine code of any processor (I say 'wasn't' because I haven't followed C# in a while; they may have built one since). C# programs are run by what is often called an interpreter even though C# runtime has always compiled to machine code on the fly. In a C++ program, the progammer has manual access to freeing memory (as well as the pointers to/within it). A C# program uses the garbage collector to take care of freeing memory (as in, C# doesn't have a 'delete' operator, just 'new').

 

Some people might even argue that C# could be faster because C# gets compiled on the fly, the runtime knows exactly what the best actual machine instructions are for the users exact hardware (as opposed to a C++ compiler having to target some lower denominator of CPU like no-SSE, unless you actually provide multiple binaries for users to choose from or users compile themselves).

 

The fact that a C++ will never slow down, use an extra thread (or *gasp* pause) for a garbage collection is probably one of best ones for people who like control. I thought was going to come up with better arguments, but other than memory access and allocation, it's late and I'm drawing a blank. The runtime compiling C# bytecode on the fly takes time too, and I imagine there's a threshold of how many interprets of the function before it decides to compile.


PARTNERS