What's the difference between C++ and C#?
C#
Miscellaneous Forums/General Discussion/C# C# doesn't suck.
Lol! Somehow I think I was looking for a little more info.
I found this on a forum, so i can't vouch for the validity of these claims, but I've always wondered myself:
Difference between C# and C++
1. C# does not support multiple inheritance.
2. C# does not support pointer types for manipulating. However, they are used in ‘UNSAFE CODE’.
3. We can only create objects using new keyword.
4. Arrays are classes in C# and therefore they have built in functionality for operations like searching, sorting and reversing.
5. Arrays are referenced types rather than value types as they are in C++ and therefore stored in the heap.
6. C # does not allow silent fall through in switch statements It requires explicit jump statements at the end of each case statement.
7. In C#, switch can also be used on string values.
8. C# does not support default arguments.
9. In exception handling, unlike in C++ ,we cannot throw ant type in c#. The thrown value has to be reference to a derived class or System.Exception object.
10. We can’t access static members via an object , as we can in C++;
11. C# defines null as a keyword and considers it as an intrinsic value.
12. General catch statement catch(…) in C++ is replaced by simple catch in C#.
Features of C++ which are dropped
1. Macros
2. Multiple Inheritance
3. Templates
4. Pointers
5. Global variables
6. Default arguments
7. Constants number functions
Enhancement to C#
1. Automatic Garbage Collection
2. Versioning support
3. Strict type safety
4. Delegates and events
5. Boxing and unboxing
6. Web services
Difference between C# and C++
1. C# does not support multiple inheritance.
2. C# does not support pointer types for manipulating. However, they are used in ‘UNSAFE CODE’.
3. We can only create objects using new keyword.
4. Arrays are classes in C# and therefore they have built in functionality for operations like searching, sorting and reversing.
5. Arrays are referenced types rather than value types as they are in C++ and therefore stored in the heap.
6. C # does not allow silent fall through in switch statements It requires explicit jump statements at the end of each case statement.
7. In C#, switch can also be used on string values.
8. C# does not support default arguments.
9. In exception handling, unlike in C++ ,we cannot throw ant type in c#. The thrown value has to be reference to a derived class or System.Exception object.
10. We can’t access static members via an object , as we can in C++;
11. C# defines null as a keyword and considers it as an intrinsic value.
12. General catch statement catch(…) in C++ is replaced by simple catch in C#.
Features of C++ which are dropped
1. Macros
2. Multiple Inheritance
3. Templates
4. Pointers
5. Global variables
6. Default arguments
7. Constants number functions
Enhancement to C#
1. Automatic Garbage Collection
2. Versioning support
3. Strict type safety
4. Delegates and events
5. Boxing and unboxing
6. Web services
Sounds like it's just a hell of a lot easier, with maybe a bit of a speed loss
hm.. what are the diffs between C# and BMax then? It all looks quite familliar sofar..
It is much easier and speed loss on modern hardware is negligible. I am now totally converted to work in C# and Managed DirectX. It's easy, it's fast and it lets programmer to concentrate on the actual game code. I don't like MS but they got it right this time.
Barney
Barney
speed loss on modern hardware is negligible.
This type of statement always bothers me - and usually the same person then criticises Microsoft for "bloated inefficient Operating Sytems" - nothing personal Barnabius just generalising.
I think a lot of us use the modern BASIC languages to save time - but speed and efficiency should never be dismissed out of hand.
I agree. Speed and efficiency is always important (especially in game programming), no matter how powerful computers are now. If you ever plan on adding advanced AI, pathfinding, and graphical algorithms to your game, you'll need every bit of CPU power you can get. I find this to be Blitz3D's main weekness, as it is slower than many languages.
However, I have not tested the speed of C# in comparison to C++, so I don't know if the performance loss is significant or not. If not, the extra ease of use may make it superior to C++. The only reason I continue to use C++ rather than C# is mainly due to the fact that most libraries are written in C++ and are incompatible with C#.
However, I have not tested the speed of C# in comparison to C++, so I don't know if the performance loss is significant or not. If not, the extra ease of use may make it superior to C++. The only reason I continue to use C++ rather than C# is mainly due to the fact that most libraries are written in C++ and are incompatible with C#.
There is a speed loss when using C# over C++, but I would say that productivity improvements far outweigh that negative. C#, combined with a solid IDE like C# Express from Microsoft, is an amazingly productive language to code with.
About 5 years ago I saw a presentation in London by Don Box where he quite succinctly demonstrated that C# generally matches (and can be considerably faster in certain circumstances - ie. memory management) C++ for performance. Wish I could find the examples he used...
C# is not interpreted (as a *lot* of people still seem to think). It is JIT compiled - ie. it is compiled to native code when first run. So, start up is slower (as it compiles the bytecode) but thereafter there's no reason why it should be any slower than C++.
Personally I stopped worrying about it a long time ago :-)
And as Warren says, the extra productivity is another huge bonus :-)
Having said all that - I still wouldn't use it for game development. Personally I'm looking towards Java for cross-platform game development.
C# is not interpreted (as a *lot* of people still seem to think). It is JIT compiled - ie. it is compiled to native code when first run. So, start up is slower (as it compiles the bytecode) but thereafter there's no reason why it should be any slower than C++.
Personally I stopped worrying about it a long time ago :-)
And as Warren says, the extra productivity is another huge bonus :-)
Having said all that - I still wouldn't use it for game development. Personally I'm looking towards Java for cross-platform game development.
I'm considering looking at if for the x-box thingy.
you still have to program 3d collisions, and sound code with managed directx though dont you?
.
D is better than C#. It has all the advantages of C# over C++ without the speed problem. D compiles directly to native code, whereas C# still relies on a runtime VM compiling bytecodes.
Here's a comparison chart: http://www.digitalmars.com/d/comparison.html
I've got my doubts about any suggestion that C# is just as fast as C++
See the computer language shootout: http://shootout.alioth.debian.org/debian/benchmark.php?test=all&lang=csharp&lang2=gpp
Although these results are for the Linux/Mono version, the Windows/.NET results shouldn't be too dissimilar, I would expect.
Here's a comparison chart: http://www.digitalmars.com/d/comparison.html
I've got my doubts about any suggestion that C# is just as fast as C++
See the computer language shootout: http://shootout.alioth.debian.org/debian/benchmark.php?test=all&lang=csharp&lang2=gpp
Although these results are for the Linux/Mono version, the Windows/.NET results shouldn't be too dissimilar, I would expect.
C# does not rely on a VM. Programs compile to native code the first time you run them on your machine.
Not according to this decription: http://en.wikipedia.org/wiki/Common_Language_Runtime
As I understand it, JIT compilation occurs every time the program is run (immediately prior to execution). The runtime doesn't generate an independent native executable, as you seem to be suggesting. Otherwise, it would just be a straight bytecode compiler.
As I understand it, JIT compilation occurs every time the program is run (immediately prior to execution). The runtime doesn't generate an independent native executable, as you seem to be suggesting. Otherwise, it would just be a straight bytecode compiler.
If you plan on getting a career in the game industry, C++ is a must. This is based on the many "help wanted" requirements I have read for various companies.
D is better than C#.
Better is relative to the programmer's perspective, and certainly depends on what you plan to do with the language. When I start seeing jobs in D and books in D lining the bookshelves at the local technical bookstore, then it's worth some real consideration. Right now it's just another of those 'great ideas currently under development' that might just go nowhere at all.
Heck, I remember many years ago buying a Forth compiler for my Commodore 64, swapping floppies out of the 1541 drive to compile, because there would surely be plenty of jobs coming up in this wonderful language that allowed you to easily extend the language and recompile it.
For me at least, lesson learned. Sometimes the 'newest, greatest' really isn't after all.
Anyway... C# certainly has its faults. But I have no problem at all finding C# contracts for good money, and can even get quite picky about what contracts to take. Maybe someday, D will be in the running for real contract money also. For now, I'll stick with C#. Better is relative.
Mark.
If you plan on getting a career in the game industry, C++ is a must. This is based on the many "help wanted" requirements I have read for various companies.
The way MS is going C# will be very important for game writing in relatively near future. I would not stick to C++ 100% if I plan to create AAA games for years to come. Luckily I don't have to program for living anymore but if I do I'd make sure C# was high on my priorities list.
Barney
It seems some of you judge the worth of a programming language solely by it's potential to get you a job. I think that's pretty sad.
And to say that you wouldn't even consider an alternative language until you see lots of jobs appearing and "books lining the bookshelves", well that is just sheep mentality. "Baaa.. baaa... baaa!" Can't you think for yourself?
I doubt there are too many jobs out there which require skill in Blitz Basic, so how did some of you come to be posting on this sites forum?
And to say that you wouldn't even consider an alternative language until you see lots of jobs appearing and "books lining the bookshelves", well that is just sheep mentality. "Baaa.. baaa... baaa!" Can't you think for yourself?
I doubt there are too many jobs out there which require skill in Blitz Basic, so how did some of you come to be posting on this sites forum?
well that is just sheep mentality. "Baaa.. baaa... baaa!" Can't you think for yourself?
FYI, insulting people isn't the best way to win them over to your point of view.
I doubt there are too many jobs out there which require skill in Blitz Basic, so how did some of you come to be posting on this sites forum?
This seems like a valid point to make but it's completely marred by the senseless attacks in the first 2/3rds of your post. Such a shame.
Hehe, I just use the language that serves me best in whatever application I wish to create. Sometimes it's Blitz for its simplicity in dealing with graphics and sound media to design something ultra creative. Sometimes it's Visual Studio 6.0, because I'm designing something outside of the .NET structure (sometimes a program can be a pain in the butt in .NET). Other times, tho, I do use C# from VS 2005, just because there's nothing else to turn to at the time, and need a program to port into a Pocket PC or to design as a strong Windows program. Seems like for Linux or Mac programs, BlitzMax and C/C++ are my only options for those, depending on whatever it is. Right now, most of my focus is in Blitz 3D for Windows, and in screen savers.
Believe it or not, outside of gaming, I even saw some businesses here in the Cleveland area that still program in COBOL, like banks and financial institutions. Wish I knew why they didn't make any jumps to today's languages, but that's the corporate world for you.
Believe it or not, outside of gaming, I even saw some businesses here in the Cleveland area that still program in COBOL, like banks and financial institutions. Wish I knew why they didn't make any jumps to today's languages, but that's the corporate world for you.
Wish I knew why they didn't make any jumps to today's languages, but that's the corporate world for you.
Cost. What they have, works. It costs money to change it for no immediate benefit so they won't.
Sounds like you never heard of Mono then if you think C/C++ is the only option for Linux or Mac ...
And on Apple calling C++ an alternative. Don't know, Apple has their own "C#" with its objective C
C++ is good for linux. They have the same age and the same old way of working and approaching problems and solutions.
Outside I would either go with C# or Objective C depending on which side you are interested the most.
Its only a question of time until C++ something like the new Java on anything outside Linux, because I don't think Apple nor MS will accept unsafe code for that much longer so your unmanaged language will run within a sandbox which will cost it its "so called" higher performance.
PS: To those that are looking for an easy language with multiple inheritance and managed code, which is actually used in the real world, I might suggest having a look at Eiffel. Has all the Pros of C# (or vice versa to be correct as C# lend some of its technics from Eiffel) but has some stuff that otherwise only exists in either Java or C++.
And on Apple calling C++ an alternative. Don't know, Apple has their own "C#" with its objective C
C++ is good for linux. They have the same age and the same old way of working and approaching problems and solutions.
Outside I would either go with C# or Objective C depending on which side you are interested the most.
Its only a question of time until C++ something like the new Java on anything outside Linux, because I don't think Apple nor MS will accept unsafe code for that much longer so your unmanaged language will run within a sandbox which will cost it its "so called" higher performance.
PS: To those that are looking for an easy language with multiple inheritance and managed code, which is actually used in the real world, I might suggest having a look at Eiffel. Has all the Pros of C# (or vice versa to be correct as C# lend some of its technics from Eiffel) but has some stuff that otherwise only exists in either Java or C++.
Hmm, true. Thanks for pointing that out.
Now, after looking through that Borland thread, I notice that Borland has their brand of C# under the Turbo label. Now, between Borland's Turbo C# and MS's C# Express 2005, which one of these are easier, and would one recommend?
Now, after looking through that Borland thread, I notice that Borland has their brand of C# under the Turbo label. Now, between Borland's Turbo C# and MS's C# Express 2005, which one of these are easier, and would one recommend?
"In August 2000, Microsoft, Hewlett-Packard, Intel, and others worked to standardize CLI. By December 2001, it was ratified by the ECMA, with ISO standardization following in April of 2003."
If Borland has adhered to the ISO CLI Standard (look up 'CLI Infrastructure' on www.iso.org), then there is No difference in the Language itself.
There may be a difference in the Runtime implementation if they have one though. But if it uses the MS .NET Compilers, it will be 100% identical. If they have a non-standard implementation, I would stay away from it to begin with. It'll just give you headaches when trying to find example code/support for it.
Same goes for code you write with the Mono/dotGNU Frameworks.
C# code written for those will compile fine on the MS .NET compilers and vice-versa (provided you dont use any libraries that are not present in one or the other ofcourse).
ps: Mono Project and dotGNU are .NET implmentations written by the open source community and run on a wide range of hardware and both support C# as a language as C# is part of the CLI Standard. Both of them are also built according to the ISO Standard. The fact that they lag behind MS in terms of feature support is because they started a lot later and MS is part of the commitee of a few big companies that created and maintains the CLI standard. So they will prolly always be a few steps ahead of the rest.
There are some misconceptions in the list of comparissons in the first post and some other posts. I'll try to rectify them here.
C# can only inherit from 1 Class, but can inherit from as many Interfaces as you want.
C# supports 'unsafe' code blocks. Using these requires compiling your program with the /unsafe flag. Code inside an unsafe {...} block is allowed to operate on memory Pointers directly. WHle this is frowned upon, it can offer substantial speed increase when your dealing with Per-pixel manipulation of images.
Everything in C# (also the basic datatypes) inherit from the Ultimate base-class System.Object and therefor everything is handled as an Object.
Not completely true.
This is valid code:
True. C# prefers the use of Method Overloading. Meaning you create multiple methods with the same signature and add the required arguments in each version.
Like so:
3. Templates exist in C# 2.0 as Generics.
4. Pointers are accessible in unsafe code blocks.
7. If Constant member functions are Static Functions, then they are supported in C#.
Not entirely accurate. The JIT compiler only compiles a program Once. The resulting Native Code executable is then store in the system's Global Assembly Cache (GAC). This is something like a repository of Managed Programs/Dll's.
The next time you run the program, .NET skips the JIT compilation and just runs the version in the GAC.
Only if, and when, the original executable changes (new version is installed, or you re-compile from source), will the JIT Compiler recompile the program to native code.
And to skip the JIT-ing alltogether, a developer can instruct his Program Installer to Pre-compile the programs to Native Code. This way you never have the JIT-compilation step when launching the app.
If Borland has adhered to the ISO CLI Standard (look up 'CLI Infrastructure' on www.iso.org), then there is No difference in the Language itself.
There may be a difference in the Runtime implementation if they have one though. But if it uses the MS .NET Compilers, it will be 100% identical. If they have a non-standard implementation, I would stay away from it to begin with. It'll just give you headaches when trying to find example code/support for it.
Same goes for code you write with the Mono/dotGNU Frameworks.
C# code written for those will compile fine on the MS .NET compilers and vice-versa (provided you dont use any libraries that are not present in one or the other ofcourse).
ps: Mono Project and dotGNU are .NET implmentations written by the open source community and run on a wide range of hardware and both support C# as a language as C# is part of the CLI Standard. Both of them are also built according to the ISO Standard. The fact that they lag behind MS in terms of feature support is because they started a lot later and MS is part of the commitee of a few big companies that created and maintains the CLI standard. So they will prolly always be a few steps ahead of the rest.
There are some misconceptions in the list of comparissons in the first post and some other posts. I'll try to rectify them here.
1. C# does not support multiple inheritance.
C# can only inherit from 1 Class, but can inherit from as many Interfaces as you want.
2. C# does not support pointer types for manipulating. However, they are used in ‘UNSAFE CODE’.
C# supports 'unsafe' code blocks. Using these requires compiling your program with the /unsafe flag. Code inside an unsafe {...} block is allowed to operate on memory Pointers directly. WHle this is frowned upon, it can offer substantial speed increase when your dealing with Per-pixel manipulation of images.
4. Arrays are classes in C# and therefore they have built in functionality for operations like searching, sorting and reversing.
Everything in C# (also the basic datatypes) inherit from the Ultimate base-class System.Object and therefor everything is handled as an Object.
6. C # does not allow silent fall through in switch statements It requires explicit jump statements at the end of each case statement.
Not completely true.
This is valid code:
switch(val) { case 1: case 2: case 3: PerformSomeStuff(); break; case 4: DoSomeOtherStuff(); break; }
8. C# does not support default arguments.
True. C# prefers the use of Method Overloading. Meaning you create multiple methods with the same signature and add the required arguments in each version.
Like so:
void MyMethod(string a){ ... } void MyMethod(string a, int b){ ... } void MyMethod(string a, int b, double c){ ... } void MyMethod(string a, int b, double c, long d){ ... }
Features of C++ which are dropped
1. Macros
2. Multiple Inheritance
3. Templates
4. Pointers
5. Global variables
6. Default arguments
7. Constants number functions
1. Macros
2. Multiple Inheritance
3. Templates
4. Pointers
5. Global variables
6. Default arguments
7. Constants number functions
3. Templates exist in C# 2.0 as Generics.
4. Pointers are accessible in unsafe code blocks.
7. If Constant member functions are Static Functions, then they are supported in C#.
class MyClass { public static string SayHello() { Console.WriteLine("Hello"); } } ... MyClas.SayHello();
As I understand it, JIT compilation occurs every time the program is run (immediately prior to execution). The runtime doesn't generate an independent native executable, as you seem to be suggesting. Otherwise, it would just be a straight bytecode compiler.
Not entirely accurate. The JIT compiler only compiles a program Once. The resulting Native Code executable is then store in the system's Global Assembly Cache (GAC). This is something like a repository of Managed Programs/Dll's.
The next time you run the program, .NET skips the JIT compilation and just runs the version in the GAC.
Only if, and when, the original executable changes (new version is installed, or you re-compile from source), will the JIT Compiler recompile the program to native code.
And to skip the JIT-ing alltogether, a developer can instruct his Program Installer to Pre-compile the programs to Native Code. This way you never have the JIT-compilation step when launching the app.
Very interesting Jim T, I learnt some c# a couple of years ago to improve on my C++ knowledge. That info about the JIT-compilation is weird but worth knowing.
And to say that you wouldn't even consider an alternative language until you see lots of jobs appearing and "books lining the bookshelves", well that is just sheep mentality. "Baaa.. baaa... baaa!" Can't you think for yourself?
Agent Smith, I don't know why you've taken such a childish nature in your posting.Did you even read my posting, where I talked about learning Forth by swapping floppies around on a C-64 many years ago because Forth was the 'latest, greatest thing'? Where exactly is Forth today? Sure, there are compilers for Forth for every platform, even for .Net. It is hard at this point to imagine learning to program Forth and program it well, unless you just have unlimited time and a deep interest in learning arcane languages. D is currently in the same boat Forth was in many years ago, but with one HUGE difference; Forth is an easy language to learn (very easy), whereas D is barely a step away from C++ in complexity.
Time is money, and when you really think about it, isn't jumping on the "latest, greatest" bandwagon more of a "sheep mentality" approach than being more pragmatic about it and only choosing to spend the many hours it takes to learn a language well if you can see some real benefit in it to your future?
The language you are promoting, D, as being so much better than other languages competes mostly with C++. You are using a comparison chart created by the architect of the language to prove it is better; and this comparison chart has many noticeable holes where it simply doesn't mention at all features the other languages have that D doesn't. It is promoted even by it's own designer as a "systems programming language", which by itself greatly limits its audience, and makes you think twice about even bothering with a language that might not be around 10 years from now. It is not a games programming language, even though it has been used for games like every other language on the face of the earth.
Like I said in my original posting, what language(s) to choose to learn really depends on what a person's reason is to learn a language. Learning an OO language is not a matter of learning commands; the commands can generally be memorized in an afternoon. Learning a modern language and at the same time learning OO concepts, and learning to use these concepts well in any language, takes years of dedicated study and practice.
Anyway, I'm not trying to say there's anything wrong with D or any other language. The original poster asked what the differences are between C++ and C#; the assumption made here is that he is trying to decide on a language to learn (could easily be a wrong assumption). With such an extremely limited amount of information about what the original poster's intent and background is, to just jump in and say, "D is better, and here is a link to a comparison chart created by the guy that is developing D to prove it" really serves no purpose. It's an absolute guarantee that within the next few years somebody will come up with a "better" language than D, complete with comparison chart to prove it. And of course, those who don't immediately jump on this new language just have a sheep mentality, and definitely can't think for themselves.
Mark.
Ok, I apologise if I caused any offense. Yes I was being sarcastic and I'm sorry. It wasn't my intention to start a flame war, just to stimulate interesting debate.
But the point I was making still appears valid, given your latest post. Is your only gripe about Forth that you feel you wasted your time learning a language that didn't go on to make the Top Ten? I have an Engineer friend who programs almost exclusively in Forth. He can crank out apps and utilities with amazing speed and he reckons "for some reason, Forth just clicks with the way I think".
You're contradicting yourself here... is Forth hard to learn "unless you have unlimited time and a deep interest in arcane languages, etc" or is it "an easy language to learn (very easy)"? And I disagree with your assessment about D being almost as complex as C++. In fact, D was specifically designed to simplify the complicated mess that C++ has developed into.
I wasn't promoting or selling D even though, from a design standpoint, I do consider it superior to both C++ and C#. I was merely offering an opinion, trying to inject ideas to encourage people to think outside the square and not just go with the herd. I posted the link to that comparison chart because the original poster asked for comparisons between C++ and C# and it presented them in a convenient tabular format. Surely a bit more enlightening than blandly announcing "C# doesn't suck" or something along those lines.
Care to give any specific examples?
Oh really? And how is that any different to when C was first designed? Far from "greatly limiting it's audience" it went on to become one of the most commonly used languages ever. And it's still going strong 30 years later.
But the point I was making still appears valid, given your latest post. Is your only gripe about Forth that you feel you wasted your time learning a language that didn't go on to make the Top Ten? I have an Engineer friend who programs almost exclusively in Forth. He can crank out apps and utilities with amazing speed and he reckons "for some reason, Forth just clicks with the way I think".
It is hard at this point to imagine learning to program Forth and program it well, unless you just have unlimited time and a deep interest in learning arcane languages. D is currently in the same boat Forth was in many years ago, but with one HUGE difference; Forth is an easy language to learn (very easy), whereas D is barely a step away from C++ in complexity.
You're contradicting yourself here... is Forth hard to learn "unless you have unlimited time and a deep interest in arcane languages, etc" or is it "an easy language to learn (very easy)"? And I disagree with your assessment about D being almost as complex as C++. In fact, D was specifically designed to simplify the complicated mess that C++ has developed into.
I wasn't promoting or selling D even though, from a design standpoint, I do consider it superior to both C++ and C#. I was merely offering an opinion, trying to inject ideas to encourage people to think outside the square and not just go with the herd. I posted the link to that comparison chart because the original poster asked for comparisons between C++ and C# and it presented them in a convenient tabular format. Surely a bit more enlightening than blandly announcing "C# doesn't suck" or something along those lines.
You are using a comparison chart created by the architect of the language to prove it is better; and this comparison chart has many noticeable holes where it simply doesn't mention at all features the other languages have that D doesn't.
Care to give any specific examples?
It is promoted even by it's own designer as a "systems programming language", which by itself greatly limits its audience, and makes you think twice about even bothering with a language that might not be around 10 years from now.
Oh really? And how is that any different to when C was first designed? Far from "greatly limiting it's audience" it went on to become one of the most commonly used languages ever. And it's still going strong 30 years later.