Thinking Parallel

A Blog on Parallel Programming and Concurrency by Michael Suess

C++ vs. C# - a Checklist from a C++ Programmers Point of View

The NetI realize for most of you this is probably old news. I have been taking a first look at C# a little while ago, because I wanted to know if it is worth looking into, and because I am thinking about polishing up my class on Parallel Programming here at the university with a little language diversification. I have taught it using POSIX Threads before, but since everyone and their grandmother seems to use Java or C# these days, throwing in a couple of examples in these languages won’t hurt. And besides, I was curious ;) . Without having written a single line of code and just by reading the various guides available, I have come up with a list of differences between C# and C++ and thought you might enjoy reading it here.

And so, without any further ado and very brief, here is my list of differences between the two, sorted into three categories: things I like better in C#, things I like better in C++ and things where I could not make up my mind. The last subheading lists the resources on the net used to compile that list:

Pro C#:

  • garbage collection
  • array bounds checking
  • huge .NET-Framework library
  • types have a defined size (e.g. a long is 64Bit)
  • strings are encoded in UTF/16
  • autoboxing - every type can be treated as if it inherits from object
  • supports constructor-chaining (one constructor can call another constructor from the same class)
  • when a virtual method is called in a constructor, the method in the most derived class is used
  • static constructors (run before the first instance of the class is created)
  • exceptions have access to a stack trace
  • advanced runtime type information and reflection
  • supports variadic functions nicely
  • built-in support for threads
  • no need for header files and #includes
  • no fall-through on switch-statements
  • arithmetic operations can be checked for overflow if required
  • objects must have a definite value before being used
  • attributes can be attached to classes and retrieved at runtime
  • no forward declarations required, classes can be arranged at will
  • access to class members / functions is done only by the dot (no more -> or ::)
  • conditional functions (e.g. for debugging)
  • structs and classes are actually different (structs are value types, have no default constructor in general cannot be derived from)
  • supports properties
  • readonly members are const, but can be changed in the constructor
  • finally block for exceptions
  • arrays are objects
  • support for anonymous functions
  • supports the base keyword for calling the overridden base class

Pro C++

  • better performance
  • portability
  • multiple inheritance
  • deterministic destruction (allows RAII)
  • any type can be thrown as exception (only classes derived from System.Exception in C#)
  • ability to enforce const-correctness
  • implicit interfaces on generics (in C#, generics must be constrained with an interface)
  • offers pointers (C# only offers pointers in unsafe mode)
  • support for macros
  • support for global variables, functions, constants
  • allows default arguments on function parameters
  • STL
  • supports bitfields

Where C# is just different from C++

  • value types and reference types exist (struct is value-type, class is reference-type)
  • value types live on the stack, reference types on the heap
  • references can point to null (must not be valid)
  • code is packaged in assemblies in C#
  • no automatic conversion from int to bool in C#
  • main-function is called Main in C#
  • no semicolon after a class declaration in C#
  • everything derives from object or can be treated as if

Resources

Disclaimer

As you can clearly see, this is not really comprehensive. The single bullet point huge .NET-Framework library would probably fill a page at least as big as this, if it was well presented. Some categorizations may also be controversial, e.g. I see portability as a huge plus for C++, while others might not care at all (or point me to Mono). Performance is also a point where I am not so sure. I expect all the nice features of C# to bring a performance-penalty into the equation, yet if you really see this in a real-world program is an entirely different matter. But since this is by no means a comprehensive treatment of the matter anyways, you are going to have to live with it - or if you can’t, you know how to use that comment button! :P

Coming to the end of this article, I have a small request: I am looking for a good book on C# development to recommend to my students (and read myself, must not forget that :P ), preferably one that is for people with a background in C/C++ and with content on threaded programming (because that’s what the class is all about). Browsing the reviews on the net, it appears that Programming C# is pretty good, judging from the table of contents it also covers threads, but of course I don’t know how well. Do you have any other recommendations? Or can you comment on whether the book would be suited for my purpose? Your comments are (as always) very appreciated!

83 Responses to C++ vs. C# - a Checklist from a C++ Programmers Point of View »»


Comments

  1. Comment by Larry O'Brien | 2007/03/06 at 21:02:36

    I wonder if you’d consider C++/CLI as something that has many of the advantages of both C# and C++.

    Anyhow, for C# tutorials with serious threading discussions, I can say with certainty that there is no book that will satisfy you. For a general tutorial, I generally recommend Liberty. For your interests and experience, I don’t hesitate to recommend Richter’s “CLR via C#” and Hejlsberg’s “C# Programming Language” (as the reference).

  2. Comment by CaffèNero | 2007/03/06 at 22:22:26

    - “abstract classes can contain code - interfaces in C# cannot”

    …err… C# has abstract classes, too. Interfaces are just…. Interfaces. And, for good OO-programming’s sake, they should NEVER contain code. So, I’d move this one to the “Pro C#” category, reformulated as:
    “C# has interfaces, C++ doesn’t”

    - “any type can be thrown as exception (only classes derived from System.Exception in C#)”

    Forgive me, but I can’t see the problem. Again, in an OO world any exception should inherit from a base class. If you need to add custom information to an exception, just make your own exception class.

    - “C++ offers pointers”

    ….Which, again, should NEVER exist in any modern language. I agree that for low-level tricks pointers may be useful, but otherwise… stick with references.

    I could go on, but I don’t want to be pedantic… (MACROS? No, seriously… :) )

    My point is that C# has its shortcomings, but you shouldn’t overlook the major semantic cleanup which it represents compared to C++. And it has Events! ;)

    Ciao,

    Alessandro

  3. Comment by Michael Suess | 2007/03/06 at 23:50:14

    Larry: I have not looked into C++/CLI more closely, but will do so shortly. Thanks for the book recommendations.

    Alessandro: thanks for the tip on abstract classes, I have taken that point out of the article. Please also note that this is a strict feature comparison, I have not said anything about how useful these features are. But of course, your input on their acutal usefulness in practice is appreciated…

  4. Comment by Kristof Gajsek | 2007/03/07 at 09:16:12

    I’d suggest “Inside C#” (Tom Archer, Andrew Whitechapel) and “Introducing Microsoft .NET” (David S. Platt). Both include chapters on multithreading.

    As far as multithreading is concerned, I think Pro C# is the ThreadPool class and lock statement, which in most cases simplify development of multithreaded code.

    Some categorizations, as you say, may be controversial. “Huge .NET library” is a big plus when you develop a server side solution, where you control the environment. When you develop a cliend side solution, this may end up as “huge additional download and install” for users, so may be placed in “Pro C++” category. :-) Also, you can not develop system stuff and device drivers in .NET.

    If I extend Alessandro: C# has its shortcomings, but if you can live with them, it sure makes your life much easier than C++. A C++/CLI may be a good merge of both worlds.

  5. SaD
    Comment by SaD | 2007/03/13 at 21:56:42

    - multiple inheritance
    You really need in multiple inheritance? I think multiple inheritance only confused when you work on big project.

    - support for global variables, functions, constants
    Global for project? Becouse C++ not clear object orieneted language. Global variables, functions, constants in C# - you can declare in main class as static.

  6. Comment by Graeme Bradbury | 2007/03/26 at 16:08:28

    The Book “Pro C# 2005 and the .NET 2.0 Platform” from Apress is a very good all round c# book.

    “CLR via C#” by Jeffery Richter is an excellent book for people who want to know how .Net under the covers works.

    There is also a free ebook on threading in C# at: http://www.albahari.com/threading/

  7. Comment by Michael Suess | 2007/04/02 at 20:46:04

    Graeme: thanks for the tip, especially the last link looks really useful. And if a Nutshell-book about .Net 3.0 is on the way (as implied by the last link), this will definitely be useful as well.

  8. Comment by Henrik Feldt | 2007/04/20 at 20:22:13

    Don’t forget the niceties that comes from being able to use the language in the common language routine! You can import visual basic assemblies, J# assemblies, PHP assemblies,
    Boo assemblies (boo.codehaus.org), Nemerle a. (http://en.wikipedia.org/wiki/Nemerle) et cetera. :)

  9. Comment by Peter Ibbotson | 2007/04/29 at 15:44:31

    Another vote for CLR via C# by Jeffery Richter possibly the most used book I have on .net.

  10. Leo
    Comment by Leo | 2007/05/05 at 16:24:10

    I learnt my .NET from Andrew Troelsen’s book on .NET 1.0 - *highly recommended*. Now there is a .NET 2.0 version available (Third Edition) and a .NET 3.0/3.5 scheduled for this year. Large books and can be intimidating at first, but easy to read once you get started. Troelsen covers most of what one needs to write code. Richter’s book is a natural follow up. More depth, less surface area.
    http://www.amazon.com/Pro-2005-NET-Platform-Third/dp/1590594193/ref=pd_bbs_sr_2/103-4941246-7143836?ie=UTF8&s=books&qid=1178374547&sr=8-2

    Regards,
    Leo

  11. foo
    Comment by foo | 2007/07/27 at 23:28:21

    Regarding C#, how is “objects must have a definite value before being used” a pro?

  12. Comment by Michael Suess | 2007/07/28 at 00:09:33

    @foo: everything that helps to prevent errors is a pro for me. And using uninitialized objects is an error I see in students code frequently - an error that would be caught by the compiler if they were using C#…

  13. Comment by Anjuna Moon | 2007/11/06 at 13:38:50

    Hm, almost half of your “positives” on the C++ list are actually the negatives that promoted the development of C#. As a veteran C++ developer I can see where you are coming from, but you shouldn’t post views on something you haven’t grasped.

    Let’s go through some of your misconceptions:

    - Better performance : What do you base this upon? C# and C++ are both just high-level programming languages. Performance is dependant on how the compilers interpret andr translate your code and nothing else.

    - Multiple inheritance && pointers: These are two of the most important differences in my opinion. MI was nothing but a root of so many problems in a multi-developer environment. The same I can say about explicit pointers. By developing the interface and delegate-features in C# these problems have decreased a lot.
    Bottom-line in the MI-issue is - if you can’t design a model using only interface-implementation and single-inheritance then you simply aren’t fit to design it.

    - Support for macros: I tend to agree a bit, but you should look into attributes of .Net to see that there is a whole lot you actually can do to interact with the compiler. Of course this applies to C++.net as well, but now I guess we are leaving the .Net part out of the discussion.

    - It is interesting to see that you give a plus to both C# garbage collection as well as the old deterministic destruction of objects. I would like to see why this ambivalence exists. If you use C++ eg. for game-programming, sure - then a lot of your points are true, especially on the det.destruction-point.
    But since you are comparing C++ to C# we are not talking about these kind of applications and therefore there is nothing that promotes your old memory-leaking problems that even the most experienced developer creates in old C++ vs. managed garbage collection.

    - Support for globals: What kind of “global” are you missing in C#? If you haven’t grasped the namespace-system then you should study some more. In a true object-oriented model there is need for only one global - the root class. If you don’t know how to develop without using “free” globals, then you should study even further ;)

    - Supports bitfields: True enough that the language itself doesn’t support this, but again we are not discussing applications where pure mapping to machine-code is essential (if we were discussing that we wouldn’t even talk about C#). However, since C# is mainly used in the .Net environment, this is not a problem since .Net offers the same bit-array-handling you have natively in C++ and a lot more manipulation-possibilities that are not there in C++. Thus, no negative.

    - STL: You have got to be kidding me or you really have no idea of the extensiveness of the .Net-library. Nuff said on that! Jeez…

    - Portability: This remains the argument in the Java-world, but the the fact is this is not (and has not been for a long time) an issue in corporate reality. The only major shift between platforms done on a global scale the last two decades have been from old Cobol-systems to either (or both) Unix/Linux and Windows.
    What an intelligent and cost-effective enterprise today does is to utilize the power of a platform and thus using the environment best suited for this purpose. Neither Java nor C++ classic can do this, just because of the platform-independentness that many of there libraries are built upon. Therefor they are actually far weaker choices as environments.

    - any type can be thrown as exception (only classes derived from System.Exception in C#): Not sure what your getting at here so please expand that. You can catch all exceptions in try-blocks, even from unmanaged components, so what is your point?

    - ability to enforce const-correctness: Dear old discussion in the C++ community but i tend to agree with Anders Hejlsberg on this subject and do not see this as a major downer.

    Well, in conclusion - C++ is naturally the given choice in real-time or close to real-time application-development, but when comparing it to C# we are mainly in the .net-world: In this environment there is in my mind no comparison and C# comes out the winner.

  14. Comment by Michael Suess | 2007/11/11 at 22:17:04

    Anjuna Moon: Thanks for sharing your thoughts here. You raise some very valid points. Unfortunately, you have chosen to spice up your points with personal attacks, which does not help your credibility at all, in my humble opinion.

    You have also misunderstood the point of the post: I have listed all the differences I could find. Yes, that means some of them are contradictory. It is not a list of things I like or don’t like about these languages. As I have posted at the very beginning of the article, I don’t even know enough about .NET to judge that.

  15. Comment by steve | 2007/12/12 at 07:26:34

    This comparison and discussion is interesting for both the content
    and the opinions of the participants. The thought that a language
    like C# can be as efficient as C++ is false. The statement C++ can
    be as efficient as C# is true. Features such as garbage collection
    are not free - I’m sorry to say. Its also interesting to see how
    some see a sortcoming (or just a decision not to support a feature)
    as a benefit. Now that’s some great spin. I’ve used multiple
    inheritence a bunch in the past and the noone ever complained.
    Sure, I can make all of my classes derive from the exception class
    so that I can throw them. No problem. But to spin this as an
    advantage is comical.

    The question I would ask is this: if MSFT hadn’t depricated all of its
    C++ libraries in favor of C#, would there be as much of it out there
    today?

    My answer would be no…

  16. Comment by programmer | 2008/01/21 at 16:40:44

    “when a virtual method is called in a constructor, the method in the most derived class is used” - *very* dangerous behaviour, c++ is better in that aspect

    “value types live on the stack, reference types on the heap” - it depends on compiler optimizations, in c++ you have the same possiblity

    “deterministic destruction (allows RAII)” - you can use that in C#

    In my opinion you should lern little more about programming.

  17. Comment by Dragontamer | 2008/03/30 at 02:50:59

    I don’t really know C# and I appreciate the list… but I do know C++ and would like to make a few comments if you don’t mind.

    * garbage collection

    C++ has 3rd party garbage collection, and in all flavors too. You can get a reference counting GC or use a Mark and Sweep one or whatever other algorithms are out there. They work pretty well and override the global operator “new” function. Check out Stroustrup’s FAQs for pointers on this part. http://www.research.att.com/~bs/bs_faq.html#garbage-collection

    * array bounds checking

    Just pointing out that you can use std::vector.at() and you’ll get bounds checking. I find it hard to think of situations when I’d use an array over a std::vector.

    * built-in support for threads

    A valid complaint, just noting that C++0x will hopefully rectify that situation :-) (Stroustrup says “C++0x will almost certainly include a threads library.” in his FAQ).

    * no fall-through on switch-statements
    * arithmetic operations can be checked for overflow if required

    These sound pretty awesome. I’ll have to look into C# just for these feature alone.

    * objects must have a definite value before being used

    I’m somewhat confused by what you mean about this. If you don’t provide a default constructor in C++, you are forced to initialize every object, or else you get a compile time error. Perhaps you mean primitives must have definite values?

  18. Comment by JAngo 6 | 2008/06/23 at 10:33:44

    This Discussion has been a GREAT help.
    I hope more teachers as well as NOOB’s would come across this site.
    Wonderful contribution.

  19. Comment by Rhonald Moses | 2008/06/23 at 12:41:51

    Hi,

    In my humble opinion, as I use both C# and C++; it’s all about what you are planning to do and how much confident are you in handling what you do.

    I don’t see much negatives in C++ as some lazy and careless coders see here. I find Multiple inheritance feature and pointers as awesome. I have hardly had the problems that are mentioned above. A half breed programmer is always half breed despite the tool he use.

    A programming language is a mere tool that helps you create what you want.

    C++ is all about endless power at developers disposal. With power comes responsibility and so, the developer is responsible to make decisions and implement.

    I personally don’t like to be limited by the inadequacy of the programming language i use. It is my job to improve as years goes by and makes caution and clean design and goals part of my programming life.

    The way I see, the only area where C++ does not fit in today’s world is where no one gives a damn about how good the developer or a particular block of code is, but all they want is some output close to what they require.

    Developers wants to feel they are good developers right out of college. C++ takes time to learn, master and it feels great when you start using it. In fact, all this years of sound existence despite the arrivals of so called safe and powerful languages speaks a lot about the language itself.

    I am excited about C++0x and the features I’ve used so far are just awesome… I am just waiting to hear C# and Java catching up with C++ on those features soon :) … Man I just love that lambda expression feature in C++0x.

    No offense to Java/C# developers (since I do C# coding too as part of my profession). It’s the same negatives you believe are +ive for C++ and I see a very bright future for C++ than any other languages.

  20. Comment by Eric | 2008/06/23 at 15:11:13

    Good information….

    But what will happen in 10 years from now…. will C# still be there?

    If I start a software project now and I know the software has a live expectancy of 10 years and more… Should I start using C# and .Net?
    I know how things went with MFC and OWL. Specially if you look at project with a poor design.

    Let me know!!!

  21. Comment by Rhonald Moses | 2008/06/23 at 15:50:43

    Hi,

    To begin with; what I am going to say is strictly my own personal opinion, based on my past experience with both the technology, what i’ve read about them and what I have observed about the future goals.

    In my humble opinion, it’s a total waste to bank on proprietary standards and proprietary programming languages. I am not against them, but the way i see it, the open technologies are leap frogging the closed technologies. I don’t see much of bright future for c# 10 years from now where the disconnected desktops does not play much significant role.

    If it still exists (c#, etc), it will be entirely incompatible with what you develop now and most importantly the windows operating systems you will be using 10 years from now will be entirely incompatible to the software you develop right now.

    For example, I had developed a small piece of utility software during my university days (8 years back) which I still use despite the evolutionary change in C++. All I had to do was to re-compile the source code with gcc4 under linux and am still using it.

    If it’s the other way around; I’ll have to either re-develop using the framework available right now (at least a major portion of the code).

    Having said that, I am not implying that there won’t be wast changes 10 years from now. 10 years is too much ahead for us to think and so I can’t be 100% certain about anything, but i have enormous faith that C++ will sustain with big backward compatibility support.

    Java might survive (I use might since i am skeptical about the growth of java base - the size of java gets complex and bigger) since it’s open sourced.

    Though mono exists, no one is certain about the future of mono and I am sure within 3 years from now, Microsoft will be at even with Linux and other *nix operating systems. So you’ll have to take your application platform independent. In those scenarios, languages such as Java, C++ (GCC, QT), Python, Perl, PHP makes much more sense than .NET.

    I leave the decision to yourself.

  22. Comment by Ralf Sinoradzki | 2008/09/27 at 05:18:53

    I haven’t used C# so far, perhaps because I’m a bit afraid that I adopt some programming styles there that let me make more errors in c++ later.
    But today I’ve seen a video about the Currency and Coordination Runtime (CCR) that M$ is using in their M$ Robotics Studio. That programming paradigm looked interesting, so guess I have to learn C# anyway.

    For me, one advantage of C++ was always that I can really have an idea, how the code looks after compiling and what happening in memory, when it’s executing, except some low level optimizations with opcodes, inlining and such perhaps.
    So although you write object-oriented stuff, use templates etc., the code that the compiler is generating and the processor is getting to eat is exactly what you wrote. ( If you use a debugger, you can usally nail each C++ command or addressing mode down to one or a few opcodes )
    There is no hidden overhead or some mysterious stuff going on, once you understand C++ and the underlying hardware.

    The main drawback is of course that it has a steep learning curve. You need a deep some knowledge of the possible pitfalls, before you use a language feature, and you need obey some programming guidelines, otherwise C++ becomes a bug hell.

    Another thing that can be seen as a drawback is that you have to juggle with lots of libraries, which makes sense ofc from the C++ perspective, because C++ is a platform independent ISO standard. So all the stuff that’s platform specific isn’t meant to be part of the language.

    So in short, one big problem of C++ is that you have to think so much, what you are doing to avoid mistakes and that you can easily lose yourself in the details. And there is usually not one way to do something, there are several.
    Like I already said, one advantage is that once you understand the details of the language and can switch your brain to compiler perspective, you can more or less immediately see, why some code has undefined behaviour, crashes or is not efficient etc.

    One definite proof that programming C/C++ requires a lot of discipline have been the buffer overrun bugs and explots in the past. I guess most of them had either the reason bad coding style or simply that the programmer was just not understanding enough about the inner workings of c++, how the code executes and where the pitfalls are.
    Using parts of the language that you don’t fully understand or an “it compiles, so it’s working !” - mentality is suicide in C++.

  23. Comment by Jabberwock | 2008/12/08 at 02:20:32

    All I can say is every time someone tries to convince me to switch to C# from C++, I do some benchmarks and find that performance wise C++ still crushes C# by large factors (depending on the particular test). I am personally very comfortable in C++ and see no reason to switch. When I feel that C# is at least a third (on average) the speed of C++ I might consider it for some applications. Until then all these comparisions are meaningless to me.

  24. Comment by Dillon Burnett | 2009/01/13 at 06:15:54

    Something everyone needs to think about is what you are programming. If i need to do a lot off different things i use C++ (I still don’t know everything so this could be why), but if i am gonna focus on a few things some reason c# works better like. example using system files. Of course i don’t know c++ well. i can use little things, but that what the web is for!

    For good books on C# Simple Program Design C# which is for beginners and Program Design C# it is by Robertson or something, it is really good with showing easier ways to do things and how to get around walls. I got it from one of my teachers. After that i started getting into C# i never really used C# or C++ before that.

    I’m not sure what your classes are and who they are for, but also if someone wants something to do or mess with batch files are easy to make and can help speed simple tasks up! (that something for the beginners. kinda a mix of basic and C .)

  25. Comment by dave | 2009/01/23 at 20:09:26

    C++ is for those that have a strong computer science background matched with years of experiance using the language. It is just a tool that gives a lot of power to the programmer and thus how dependable and usable it is depends mostly on the ability of the programmer.

    C# and Java give less power to the programmer. Period. However for a beginer or intermediate level programmer, the baby sitting features of these languages hold serious value. The end product will be more secure, less buggy, and easier to maintain.

    I think it comes down to your background and the time you are wiling to invest.

  26. Comment by John S | 2009/02/04 at 01:21:34

    Interesting discussion, although the title is a bit of a misnomer. What is really being discussed here is managed versus unmanaged code - not C# vs C++. Both C# and C++ can create managed apps. C++ can also create unmanaged applications that are compiled directly to native code.

    Some other points for consideration:

    - As mentioned, the C# compiler does have an unsafe mode which allows pointers.

    - C++ is the only .net language that allows the creation of managed and unmanaged code in the same assembly (unsafe). Other languages can call unmanaged code (such as a windows API) but cannot create it. The following offers a nice summary of mixed mode development:
    (http://www.ondotnet.com/pub/a/dotnet/2003/03/03/mcppp2.html)

    - STL is available for managed code (managed C++ specifically) in the form of the STL/CLR libraries (Microsoft.VisualC.STLCLR.dll) in .net 3.5 distribution
    (http://msdn.microsoft.com/en-us/library/bb385954.aspx)

    - Managed code can usually accomplish the same functionality as an unmanaged app in about 35% of code that needs to be written by the developer due to the richness of the Framework - you are moving functionality from your code to the Framework. Less custom code means fewer opportunities for errors, and maintenance is easier. Managed code offers significant time savings in both coding and optimizing. Again, this is not a C# vs C++ statement, it is a managed vs unmanaged statement.

    - Although generally considered faster, being “native” is not a guarantee of performance.
    (http://msdn.microsoft.com/en-us/library/aa446521.aspx)

  27. Jim
    Comment by Jim | 2009/02/04 at 10:23:01

    dave: So, in order to be a good programmer or to have a powerful programming tool, the language must be hard and difficult to use?? Doesn’t make sense at all! It’s like saying that for you to be a good soccer player you should put some nails in your shoes…

  28. Nrx
    Comment by Nrx | 2009/02/22 at 11:06:39

    Recently I have been learning both C++ and C#. I have been avoiding CLR C++ as I cant see a point to managed C++ other than a very slight compiler optimization performance gain over C#. But C# seems to be much more productive and easier to learn and I find myself spending less time programming things that are of no relevance to the application I am developing, where as in C++ I find much time spent handling things that provide no functionality to the application but rather enable functionality.

    As for the threading and paralell programming topic, the .net framework makes it very easy and safe, I have not tried threading in native C++ but judging by what I have learnt so far, it will be a much more trechorous and unproductive endevour than in .net

    Just my 2 cents

  29. Comment by Alberto | 2009/04/03 at 14:39:19

    Hi

    In my opinion, the important thing about programming is not the skills the programmer shows, but the usefulness and stability of the applications. If the software is good, fits the clients, and is stable, it doesen’t matter what lies behind it, providing the programmer is able to mantain and further develop it properly.

    In this context, obviously C++ and C# live together in the deep and wide space of the programming sky, and are aimed at different kind of users, and different purposes. It’s useless to compare them side by side, because they are complementary, and so, the users benefit from the fact that there are two alternatives and not one, as before C# came into view.

    Clearly, C++ and C# have advantages and disadvantages, as everything in life. The choice will depend on many factors, and of course, one of them is the skill of the programmer. But others are: readability of the code, maintainability of the code, portability, etc.

    Finally, I am surprised to find such a hard defense of C++. C++ is undoubtely great. But many applications developed in it aren’t so great. In fact, many of them are awful, and that makes all of us suffer with erratic behaviour and random hangups while doing our everyday job. I am sure that if those applications had been developed using C# instead of C++, this would happen less. So, if the programmers aren’t just skilled enough to use a language as powerful as C++, well, we have two options: Have them all sent to intensive courses, or have them learn a language which is more suitable to them. Second is far much better, don’t ya think?

  30. Comment by Concerming multicore Programming | Colin B Maharaj | 2009/04/03 at 16:25:30

    I am a c++ Programmer
    Concerning threading and multicore programming, I attempted to give a go at this a few months back, even looking at some oneline MIT lectures on algoritms.

    The fact is that, at least for me, it is not too hard for me to write threading code. I use C++ Builder and it works for me.

    But the main concern is identifying where your code will be a good candidate for multicore development. E.g. sorting.

    I can sort 1,000,000 numbers serially (one thread) or split the list in two sort 500,000 in two threads then merge and get a performance increase by 95%

    But you have to knoe the algorithms and you got to have to vision to know what part of your code can benefit from this.

    These skills has nothing to do with the language set. Once you support threads, as far as I am concerned, you support multicore programming.

  31. Comment by Eric | 2009/04/24 at 06:29:37

    I think fall-through in switch statements is actually an advantage in C++. In C++, switch fall-through to avoid duplication of code for multiple cases. To achieve the same thing in C#, you would have to create a function to be called in each case.

    Also, you left off an important difference: C# supports only the object-oriented paradigm, forcing you to create a class for everything (stand-alone functions in C++ would become static methods in a class in C#), whereas C++ allows either object-oriented or procedural programming. People have different opinions on whether it’s better to force object-oriented programming or to support both styles.

  32. Comment by Eric | 2009/04/26 at 11:22:08

    You left out another important difference: C++ supports both object-oriented programming and functional programming, whereas C# supports only the object-oriented paradigm.

  33. Comment by Eric | 2009/04/27 at 00:59:41

    “C++ has 3rd party garbage collection, and in all flavors too.”

    True, but it’s nice when a feature is included with a language or its libraries, so that at least for portability reasons, you can be assured it will be there. In C++, there are certain things (such as garbage collection, GUI library, etc.) where you have to search for and decide on a 3rd-party library, and then you are stuck with whatever they release and are limited to whatever machine/OS platforms they release it for. For some, that’s not an issue though. Another disadvantage of 3rd-party libraries is that companies often charge quite a bit of money for their library.

    “Just pointing out that you can use std::vector.at() and you’ll get bounds checking.”

    That’s true, if you’re using a std::vector. However, that doesn’t apply if you’re using one of the myriad other types of collection classes out there.

    “I find it hard to think of situations when I’d use an array over a std::vector.”

    If you’re ever sending data over a socket or a pipe, you need to use plain arrays. You can’t transfer complex objects via sockets (you can only use the basic built-in types), and that might be true for pipes too.

    ” * no fall-through on switch-statements
    * arithmetic operations can be checked for overflow if required

    These sound pretty awesome. I’ll have to look into C# just for these feature alone.”

    Personally, I think lack of fall-through on switch statements is a disadvantage. Fall-through is useful when you want to use the same code for multiple cases in a switch, and to duplicate that in C#, you’d have to create a function that would be called in each case. The only reason I can think of why switch fall-through is not supported in C# is to avoid bugs caused by leaving out a break statement. Well, that’s not a hard bug to fix, really. So I don’t consider lack of switch fall-through to be a benefit.

  34. Comment by Erik2 | 2009/05/20 at 16:38:47

    C++ Still wipes the floor with C#. I have tested many times (even with 2008). I think the best I got for C# was 2.4X slower. The worst case was about 10X. I even had one case where I wrote my own custom heap in C++ and I got 42X faster. I won’t count that however. But it does point out a major advantage of C++. You can really customize things if want to go that far. I’ve seen a lot of C# vs C++ benchmarks posted by C# fanboys. I tend to consider them a lot of BS. Mainly because just writing your average test such as a sort or something along those lines, C# never even comes close to C++. In a 200K line application you aren’t going to go over every routine with a toothcomb trying to optimize it. C# is a decent language but I’m simply not even going to consider writing performance sensitive code in it as it stands. My numbers show it’s slower and real world experience with applications shows its slower.

  35. Comment by Eric | 2009/05/20 at 17:33:54

    I think it’s expected that C# would be slower than C++, given its garbage collection and the fact that it runs in a virtual machine. I think the real question is whether the speed difference affects the task at hand. Fortunately, you can still write in C++ in .NET using Managed C++, and you can call Managed C++ code from C#.

    Recently I found that if you want to use standard C++ (not Managed C++) code from .NET/C#, you can create a Managed C++ wrapper for it.

  36. Comment by Erik2 | 2009/05/21 at 00:46:59

    In my view managed C++ is the worst of both worlds. It’s not really C++ and in general just messes you up. I would use C# before managed C++. Again I don’t consider C# a bad language, just kind of slow. I might use it for some things due to ease of programming. However in most cases I end up working on stuff like games where the performance matters so anything other than C++ goes out the window. I’m still waiting for a new latest greatest compiled language to become accepted without all the quarks of C++. However at this stage of C++ is the only option for most of my work.

  37. Comment by Eric | 2009/05/21 at 01:46:39

    I do like C++ for its speed, and much of my own experience has been with C++. I agree with you that Managed C++ isn’t a language I’d choose to use, but if you ever find yourself in a job requiring you to use C# and you need to use some legacy C++ code, you’d have to do some Managed C++ to bridge the gap.

    I am a bit disappointed that most new programming languages that come about these days tend to use a runtime (i.e. Java and C#) or are interpreted (Perl, Python, PHP, etc.).

    Speaking of new compiled languages, there is a newer compiled language that I’ve heard about but haven’t used yet, called D: http://www.digitalmars.com/d

  38. bob
    Comment by bob | 2009/07/14 at 02:40:43

    I recomend a book called learn to program with C#
    By John Smiley It teaches in a strange but easy to understand way it`s
    like he teaches you in first person like your actually there any way
    i am under 13 and understand it. And expects no prior knowledge of
    any language.
    Cons:
    Teaches You In Note Pad
    Old book but still relivent
    Pros:
    Very good book easy to understand
    Even i can comprehend it:!:

  39. Comment by Arup | 2009/08/06 at 11:12:57

    Hello every one. I am a beginner in programming and was thinking what language to start with. On a web search regarding this I come a cross with this article and I have read all the comment posted on. But as I don’t any thing about any programming language what so ever it seems like thing flying above my knowledge antenna. Sorry for the interruption but as all experienced programmers are on board I was just being opportunist to ask if any one can suggest me language that I can start with. Your suggestion will very much appreciated. Thanks

  40. Comment by Eric | 2009/08/06 at 19:28:44

    Arup: From a practical standpoint, I think C# would be a decent first language to learn. It’s a modern language that is used by many companies and many people.

    However, there are features that C# doesn’t have. In the past, it has been said that C++, although possibly intimidating at first, is a good first language because C++ has many features that aren’t found in other languages (multiple inheritance, as an example). And people have said if you can learn C++, you can learn any language.

  41. joe
    Comment by joe | 2009/08/22 at 05:49:47

    I’m using both. C++ code for performance critical code and C# for database CRUD code.

    I feel a bit more loyal to C++, and it doesn’t really have to do with the language, I don’t really like the bully/illegal tactics of the company who makes .NET.

  42. Comment by saleh | 2009/08/26 at 06:52:14

    hello i dont like to chang ur topic .

    but i think you can use python and have a lot of advantage that there are in c# and c++ together. :smile:

    good luck for all of you

  43. Comment by Itay | 2009/08/31 at 03:26:21

    I used to think C# is much better.. but god damn, C++ got huge design advantages.. the generics are like class parameters, you can send any type of object (3, “abc” new Date()), while in C# you can only send a type (string, int, etc.)…
    not to mention the multiple inheritance…

    too bad C++ got such a ugly syntax.. and a lot of other disadvantages XD..
    actually i still think C# is much better.. but why the hell did they give up the C++’s generics??

    and BTW, you have mentioned a lot of C++ advantages which are actually dis advantages.. for example:

    any type can be thrown as exception (only classes derived from System.Exception in C#)

    this is much less organized like this..

    and this:

    allows default arguments on function parameters

    exist in C# 4
    (don’t ask me what took them so long)

  44. Comment by Eric | 2009/08/31 at 04:27:57

    I guess any feature could be considered an advantage or a disadvantage, depending on how you look at it.

    Being able to throw any type as an exception is flexible, and isn’t really a problem if you have a catch (…) block, which will catch anything. I guess the problem is that it can be hard to know what will be thrown in C++, so I think C#’s exceptions are nice in that you can always catch System.Exception as a default and still be able to look at some of the properties of the exception object.

    I’ve also heard some people say that C# is slow compared to C++, and some things that need the speed still need to be done in C++. For speed, I wish C# would at least compile down to native code rather than a runtime object (C# apps use the .NET runtime, similar to Java apps using the Java runtime). Also, C#/.NET’s garbage collector adds an element of randomness to the application, which might sometimes be a bad thing..

  45. Sam
    Comment by Sam | 2009/09/11 at 11:12:55

    I think if somebody wants to work in Microsoft, he or she must learn C#.
    For the beginners I can just say start with C programming language and then pick C# or Java.

    The point is her to understand programming and to produce something which can be achieved in quickest possible time.

    C++ is hard to learn and master but to learn C++ you need a professional programmer who at least have 5 to 10 years experience in C++.

    A cook book or a beginning book can’t help you to learn C++. A good teacher/programmer can really tell you how to learn C++ without mistakes. I started to use C++ after C and Java/C# programming projects and use to be in love with C++, because of its compile time performance its rocks, but I feel my self home init, because I have learned good object oriented skills in C# and Java.

  46. Sam
    Comment by Sam | 2009/09/11 at 11:14:49

    I think if somebody wants to work in Microsoft, he or she must learn C#.
    For the beginners I can just say start with C programming language and then pick C# or Java.

    The point is here to understand programming and to produce something which can be achieved in quickest possible time.

    C++ is hard to learn and master but to learn C++ you need a professional programmer who at least have 5 to 10 years experience in C++.

    A cook book or a beginning book can’t help you to learn C++. A good teacher/programmer can really tell you how to learn C++ without mistakes. I started to use C++ after C and Java/C# programming projects and use to be in love with C++, because of its compile time performance its rocks, but I feel my self home init, because I have learned good object oriented skills in C# and Java.

  47. Sam
    Comment by Sam | 2009/09/11 at 11:17:21

    Some Books by Bjarne Stroustrup the inventor of C++.
    • Bjarne Stroustrup: Programming — Principles and Practice Using C++. December 2008. Addison-Wesley. ISBN 978-0321543721. 1264 pages. Softcover.

    • Bjarne Stroustrup: The C++ Programming Language (Special Edition). Addison Wesley. Reading Mass. USA. 2000. ISBN 0-201-70073-5. 1029 pages. Hardcover.

    • B. Stroustrup: The C++ Programming Language (3rd edition). Addison Wesley Longman, Reading, MA. 1997. ISBN 0-201-88954-4. 920 pages. Softcover.

    • Bjarne Stroustrup: The Design and Evolution of C++. Addison Wesley, Reading, MA. 1994. ISBN 0-201-54330-3. 472 pages. Softcover. (Often called D&E).

    • Bjarne Stroustrup: The C++ Programming Language (2nd edition). Addison-Wesley, Reading, MA. 1991. ISBN 0-201-53992-6. 696 pages. Softcover.

    • Margaret A. Ellis and Bjarne Stroustrup: The Annotated C++ Reference Manual. Addison-Wesley, Reading, MA. 1990. ISBN 0-201-51459-1. 478 pages. Hardcover. (Often called “The ARM”)

    • Bjarne Stroustrup: The C++ Programming Language. Addison-Wesley, Reading, MA. 1986. ISBN 0-201-12078. 326 pages. Softcover.

  48. Sam
    Comment by Sam | 2009/09/11 at 11:18:47
  49. Comment by Mirek | 2009/09/12 at 12:02:49

    IMHO only C# advantage over C++ are it’s more extensive libraries.

    * garbage collection
    3rd party or your own library. actually it’s easy to code (however has uses only when coder is lazy, because one which isn’t lazy makes his own heap)

    * array bounds checking
    hmm.

    * types have a defined size (e.g. a long is 64Bit)
    that is why there are macros for your code to see under which compiler you’re compiling. make your own long

    * strings are encoded in UTF/16
    wchar_t (windows UTF16, unix usually UTF32)

    * autoboxing - every type can be treated as if it inherits from object
    ehm.. C# Best Practice - Do not use boxing and unboxing.

    * supports constructor-chaining (one constructor can call another constructor from the same class)
    that is why I usually write init method

    * static constructors (run before the first instance of the class is created)
    static instance in class

    * exceptions have access to a stack trace
    easy to do if you can take being platform dependant

    * advanced runtime type information and reflection
    if you intend to do this (say with serializable objects etc.) you may as well write it.

    * supports variadic functions nicely
    well as boxing isn’t recommended…

    * built-in support for threads
    once again, it’s just classes written for C#. I haven’t noticed any autolocking of variables used between different threads

    * no need for header files and #includes
    well, I guess this is plus

    * no fall-through on switch-statements
    as I actually use them sometimes, it means extra goto line

    * arithmetic operations can be checked for overflow if required
    well, once again this can be considered plus. however the expense of this is very close to doubling integer size and then checking upper half if overflow occured. so can as well be done C++

    * objects must have a definite value before being used
    considering the way C# handles member variables initialization (e.g. if not specified zero), it’s IMHO worse than not initializing them at all.
    besides that some C++ compilers also give warnings about uninitialized variables.

    * attributes can be attached to classes and retrieved at runtime
    well, it isn’t bad at all. but as one can guess, you can make your own base class for all classes you write thus having same functionality.

    * access to class members / functions is done only by the dot (no more -> or ::)
    well this is about the “no pointers” in C#, no pointers no deref.

    * conditional functions (e.g. for debugging)
    hmm?

    * structs and classes are actually different (structs are value types, have no default constructor in general cannot be derived from)
    well, I guess this comes from what C# is. struct is value while class is object. I don’t really see a + here. it’s just different.

    * supports properties
    behind the scene on += with properties C# compiler does get and then set. I really see no positive in this. otherwise it’s nice if you need some validation of input. but IMHO input should be validated on input instead per every set.

    * readonly members are const, but can be changed in the constructor
    never had need to have const member taking space in instance.

    * finally block for exceptions
    once again some C++ compilers have this extension (guess who’s), however can be as well emulated with try-catch which will compile anywhere

    * arrays are objects
    as are std::vector, std::deque etc.

    * support for anonymous functions
    templates

    * supports the base keyword for calling the overridden base class
    once again some C++ compilers have __super. however this only works as hoped for with single inheritance and thus may instead bring bugs instead of reducing them. (AFAIK that is why it was rejected by other than M$ compilers)

    It may seem I dislike C#. it isn’t truth, it actually saves you some typing time. I just like C++ a lot more. In the end it’s only about the libraries you have and use for which language. If you have them for C++ you don’t need C#.

  50. Comment by Eric | 2009/09/12 at 21:26:56

    Mirek: I think you have some valid points, but I think some of the points in favor of C# are good, too.

    I’ve used C++ quite a bit in the 5 years I’ve been doing software professionally, and I like C++. However, with some of the frustrations I’ve experienced with C++ and the time taken to do certain tasks, I can appreciate some of the features of C#.

    As a more recent language, the C#/.NET standard library includes things that are used more recently, such as threading, GUI API, sockets, etc. Including things in the language’s standard library is very beneficial, I think, because that means they will (or should be) included in any standard implementation of the language, so you don’t have to worry about your software running only on one particular platform because one of the libraries you use only works on that platform. For instance:

    * Standard thread class
    As you say, this is simply just a threading class written for C#, but the difference is that it’s part of the .NET standard library. Thus, you can be assured that it will be there on any platform where .NET is implemented. So, even the Mono runtime (for Linux) would include this class.

    * Standard GUI API
    WinForms is the GUI library that is part of the .NET standard, meaning you don’t really have to worry about which GUI library to choose and if you will be limited to one platform. The Mono runtime added support for WinForms a while ago, so you should be able to run WinForms apps on Linux now, rather than just Windows.

    * Standard sockets API
    Again, this is useful because many apps these days require networking support.

    With C++, if you want any of these features, you have to go look for what libraries are available to support these features and also consider what platform(s) those libraries support, then how to install those libraries (if you don’t have them already), etc.. It’s nice to have features that are already there, part of the standard of the language. Additionally, since C++ does not include things like a GUI library, threading, etc. in its standard library, many different projects use different libraries, so as you take a look at different C++ projects, you have to spend time getting familiar with a different library, perhaps making it compile on your computer (if it doesn’t already), etc..

    Also, you’ve talked about the following:
    * objects must have a definite value before being used
    I think this is actually a good feature in C#. It’s better than letting a variable have some random value based on whatever is in memory at the time the variable is allocated. Predictable behavior is better than random behavior. Also, by refusing to compile code that doesn’t initialize variables, C#’s compiler forces you (perhaps reminding you) to initialize your variables, which helps prevent unintended random behavior.

    * finally block for exceptions
    You say this can be emulated with try-catch? The finally block is in addition to try-catch.. So I’m not sure how you can emulate a finally block with a try-catch. You also say that some C++ compilers support a finally block - But it’s certainly not a standard in C++. Again, having a feature as standard means you can (or should always be able to) always rely on that feature being there.

  51. Comment by Mirek | 2009/09/14 at 19:24:16

    @Eric
    - You say this can be emulated with try-catch? The finally block is in addition to try-catch.. So I’m not sure how you can emulate a finally block with a try-catch

    class nothing : public std::exception {};

    #define _TRY try { try {
    #define _END_TRY throw nothing(); }
    #define _FINALLY catch (…) {
    #define _END_FINALLY throw; } } catch (nothing&e) { }

    void test() throw(…)
    {
    void * ptr = 0;
    _TRY
    ptr = malloc(1);
    throw 0;
    _END_TRY
    _FINALLY
    if (ptr)
    free(ptr);
    _END_FINALLY
    catch (int e)
    { }
    catch (…)
    { }
    }

    finally is executed before catch (which may or may not be a problem), can’t think of a way to put it after catches atm. anyways it’s ugly and IMHO it’s better to depend on RAII

    As for .NET being multiplatform, I have to agree that is a big +, but IMHO remains to be seen how much multiplatform it will be (or how delayed the other platforms will be). Didn’t seen too much effort on M$ side. (but maybe it’s just me not reading news).

  52. Comment by Eric | 2009/09/14 at 19:46:11

    Mirek - I’m not quite sure I understand how that emulates try/catch/finally as seen in C#. The 0 is thrown before you use the _END_TRY, so the nothing will not get thrown. And since your _FINALLY macro catches anything, the 0 that you throw would be caught by the _FINALLY block; is that the behavior that is intended? I’m also used to seeing a finally block at the end of all the catch blocks.. In C#, I had thought the finally block had to be at the end (after all catch blocks), but doing a search, maybe it’s not.

    As far as .NET being multi-platform, you’re right that Microsoft hasn’t put forth the effort to implement it for other platforms. That’s something I don’t really understand. .NET was designed to be a multi-platform runtime, like Java, and .NET applications can run anywhere the .NET runtime is available. I don’t know why Microsoft went through the effort to make a multi-platform runtime environment but only implement it for Windows. They probably feel that they would lose market share if they implemented it for Linux or OS X. In that case, they could have made .NET applications faster and more efficient by making .NET languages compile directly to a native executable rather than something that requires a runtime.

    Mono, the .NET runtime for Linux and other operating systems, was made by other companies. That is what has brought .NET to Linux, but being made by a 3rd party, it’s at least one revision behind Microsoft’s spec. The current version of .NET is 3.5, but last I heard, Mono still only implements version 2 of the .NET runtime.

  53. Comment by Mirek | 2009/09/15 at 12:39:28

    Eric - the previous code works fine (but _FINALLY was called before any user defined catch) and return was not handled (forgot about that). the following works exactly like C# (unless I forgot something again) try-catch-finally, but it’s slow, hard to use, and really ugly.

    class nothing : public std::exception {};

    #define _TRY \
    { \
    int __my_status = 0; \
    try \
    { \
    try \
    { \
    try \
    { \

    #define _TRY_V(return_type) \
    { \
    int __my_status = 0; \
    return_type __my_return; \
    try \
    { \
    try \
    { \
    try \
    {

    #define _END_TRY \
    throw nothing(); \
    } \
    catch (nothing&e) \
    { \
    throw; \
    }

    #define _FINALLY \
    throw nothing(); \
    } \
    catch (…) \
    {

    #define _END_FINALLY \
    throw; \
    } \
    } \
    catch (nothing&e) \
    { \
    if (__my_status) \
    return; \
    } \
    }

    #define _END_FINALLY_V \
    throw; \
    } \
    } \
    catch (nothing&e) \
    { \
    if (__my_status) \
    return __my_return; \
    } \
    }

    #define _RETURN \
    { \
    __my_status = 1; \
    throw nothing(); \
    }

    #define _RETURN_V(return_value) \
    { \
    __my_status = 1; \
    __my_return = return_value; \
    throw nothing(); \
    }

    int test()
    {
    // the _V macros can return value
    _TRY_V(int)
    // something. to return from here _RETURN macro is required, as return does not run _FINALLY block
    _RETURN_V(0)
    _END_TRY
    // user defined catch block(s)
    catch (…)
    {
    // something. to return from here _RETURN macro is required
    _RETURN_V(-1)
    }
    // required finally block
    _FINALLY
    _END_FINALLY_V

    return -2;
    }

    Oh well, end of not really related stuff to this article.

  54. Comment by UUps | 2009/09/18 at 00:19:38

    Wow,

    regarding the original item “C++ vs. C#”, (btw: started about 2 1/2 Years ago) the discussion went a little bit “out of range” (that’s my opinion, of course).

    What culd be better: C# or C++? (I think, that could be the original question :wink: ). My answer: It depends on the experience of the programmer, the software that has to be developed and on the development utilities that are avail.

    I am actually developing in C++, and my last researches “said” I do it in future as well.

  55. Comment by Matt Osborn | 2009/10/25 at 16:25:58

    Whatever can be done in C# can be done in C++. The reverse, however, is not true.

    C# has a huge advantage with its .NET platform. C# has a huge disadvantge as it is limited to its .NET platfrom.

    The real advantage to C# is not language specific as C++ is clearly superior in that regard; it is the cost of software development, i.e. progammers, where C# offers tremendous advantages.

    C# programmers need not understand the differences between pointers and references; nor must they understand the relationships between the stack, the heap and static objects.

    C# programmers need not concern themselves with multiple inheritance or the advantages of the same.

    C# programmers need not concern themselves with coding embedded software as they cannot do so.

    C# programmers need not concern themselves with the intricacies of memory management, nor are they able to avail themselves of its advantages.

    C# programmers need not concern themselves with computing’s ‘big picture’; it is hidden from and managed for them.

    C# programmers will initially be more productive, but will soon plateau, finding themselves repeatedly grinding out boring and uninteresting variations of the same code.

    If you are desirous of a creative career in computing programming, C++ offers far more opportunities.

    C# programmers will tend to be less flexible, less creative and cheaper than the experienced C++ programmer.

    In summary, C# is a manager’s language choice while C++ is the language choice of the programmer.

  56. Comment by Nicholas | 2009/11/13 at 23:48:56

    Matt this comment is true

    C# programmers will initially be more productive, but will soon plateau, finding themselves repeatedly grinding out boring and uninteresting variations of the same code.

    If you are desirous of a creative career i

    I hate my job….. I’m so sick of the reputation.

    Im sure C++/CLI will make a difference but unsirtin because of silverligt and WPF

  57. Comment by John | 2009/12/12 at 20:31:18

    Getting back to the original topic of the post: As someone who has programmed in C++ for over 10 years, it’s good to see a resource that helps me understand the differences I am running into as I start learning C#. So thanks for the original article.

    As for the rest of the comments, they remind me of the old C vs. Assembler (or was is Pascal vs. Assembler) debates of a couple of decades ago.

    So, to add some more fuel to the fire:

    - What are you writing code for. C# will never be able to run on a truly embedded system where 64M (not G) of combined code and data space is huge. C++ can be used (but one has to be careful).

    - C++ is dangerous. As I once read “C++ let’s you shoot yourself in the foot with style.”

    - Discussion of the language should be separate from the discussion of the support frameworks and toolsets as much as possible. It’s easy to throw mud at C++ and say it doesn’t have as much power as the .NET libraries for C#. But it’s like comparing a diesel motor to a car. Yes, one has seating for 5 and the other doesn’t, but they are different things. If you really want to compare library support and frameworks, then you need to consider Qt and GTK and other C++ friendly frameworks. (I personally love Qt — it’s a lot more than just a graphics layer.)

    - C++ will always run on more platforms than C#, simply because of the need for the management layer.

  58. Comment by Tom R | 2009/12/27 at 11:56:52

    John said, “- What are you writing code for. C# will never be able to run on a truly embedded system where 64M (not G) of combined code and data space is huge. C++ can be used (but one has to be careful).”

    That’s not necessarily true. The .NET Micro Framework is designed to run on devices with very little memory, much less than 64MB (closer to 320kB actually.) The framework even includes a managed device driver model for writing device drivers in C#.

    http://www.microsoft.com/netmf/default.mspx

    The newest version of the .NET Micro Framework was also open-sourced under the Apache 2.0 license.

  59. Comment by Bartosz Bielecki | 2010/01/14 at 14:52:57

    In an age of grandmothers knowing C# & JAVA, I would like to say a few good words about so despised C++.

    Short rundown of my comments to your pros/cons list:
    —– C# —–

    Garbage collection:
    It’s hard to say whether or not this is good feature. Sure, it’s nice to have it and make the machine deal with your laziness, but you pay a high price with decreased system performance, which is something you don’t want to do. And don’t let anyone sway you by saying “Who cares about self-resource-management in times of iCore7?”.

    Array bound checking:
    std::vector?

    Huge .NET-framework library:
    Awesome stuff, true, but don’t forget about STL, Boost and thousands of great C++ libraries spread all over internet.

    Types have defined size:
    Plus, period. Thankfully we have a preprocessor to ease our life a bit.

    Strings are encoded in UTF-16:
    You can use wchar_t, or wait for C++0x (right around the corner) for some serious UTF-8 support.

    Constructor chaining:
    C++0x delegations.

    Advanced RTTI:
    I don’t extensively use RTTI, and I don’t find it that interesting. IMHO!

    Supports variadic functions nicely:
    If we mean the same, take a look at Variadic templates (C++0x).

    Built-in support for threads:
    There isn’t one in C++, yet, but there are already a few libraries for handling threads (eg. Boost). In C++0x, however, there will be a real support for threads.

    No need for header files and #includes:
    I got used to them, so it’s not that bad for me :) .

    No fall through through switch statement:
    That is just another approach to case-switch. If you use case-switch ONLY to have a if-type list of possible values of a variable, then you are probably happy. On the other side, C++ allows nice techniques, so that for example some steps are omitted, when not needed, and you can clearly see on what ‘level’ of case some things will happen. Oh, and don’t tell me that writting break; is so painful.

    Value must have a definite value before being used:
    Good C++ practice made as a rule in C#… and this time it’s really helpful.

    Only dot operator:
    Hmmm… is it that good? I mean, it’s very convenient, but not knowing whether or not you are calling the method by a pointer, by a normal reference to an object, or as a static method of a class, makes me wonder if you can understand your code. I like the . (dot) -> (arrow) operator distinction as I know on what kind of data I am working.

    Arrays are objects:
    As are std::vector elements.

    I would like to end my comment with saying, that I - in fact - see many pros of C#, but imho it’s a language who basically tells you this:”you don’t have to (have limited or no access to) understand inner workings of your code - happily write your code and everything will be done for you; who cares about performance in era of super-fast computers, anyway?”.

    Tom R said:
    “That’s not necessarily true. The .NET Micro Framework is designed to run on devices with very little memory, much less than 64MB (closer to 320kB actually.) The framework even includes a managed device driver model for writing device drivers in C#.”

    Don’t feel offended but you amused me :) . 320kB?? And C# developers feel proud of themselves? Recently I programmed an ATmega8 which *8*kB of memory. I wrote the code in C, but I had like 4kB left, thus I am pretty sure I could be able to write the code in C++. You were probably thinking about some TRUE devices like palmtops or such things, but even taking really powerful AVR, you get only 128kB. With such amount of memory you can create a serious program in C++, and I doubt you even write a single line of code in C#.

  60. Comment by Eric | 2010/01/14 at 20:39:34

    Bartosz Bielecki - Even though I’m far more experienced with C++ than with C#, and I like C++, I can understand some of the things in C#, which you have discussed:

    Only dot operator:
    The reason C# has only a dot operator is because everything is a pointer by default in C#; C# doesn’t need two different operators for accessing object members. When you understand the language, you won’t have a problem understanding your code, as you say.

    Advanced RTTI:
    I think it’s actually a really nice feature for a language to be able to let you analyze the objects and types you’re dealing with at run-time. One thing this helps with is loading objects and functions from a DLL. With C++, you have to jump through some hoops to use DLLs because everything with C++ needs to be defined at compile-time. However, C# can simply open a DLL and give you a list of the objects/functions in the DLL at run-time, which makes it easier to use the DLL.

    Garbage collection:
    While I agree with you that it’s hard to say if this is a good feature, I’ve heard people say that garbage collection can actually improve performance because you aren’t de-allocating your objects all the time. By deferring that operation, they say, you can actually get improved performance in the short term, and the garbage collection system can wait until the application is idle to collect the garbage. That said, though, I’m all for doing careful memory management, so I’m not really sure that garbage collection is a compelling feature.

  61. Comment by Tom R | 2010/01/20 at 02:12:14

    @Bartosz

    What does programming on at ATmega have to do with my comment? I was responding to someone’s claim that you cannot develop C# programs that will run on devices with less than 64MB of memory. I mentioned that it is in fact possible utilizing the .NET Micro Framework.

    I’m very happy for you that you’re such a great developer you can write a program in C and run it on a ATmega8. You must be a very capable programmer.

  62. Comment by Rhonald Moses | 2010/01/20 at 04:48:36

    I see that even after 2 and half years, this thread is alive :-)

    In short; C++ is a good language which can be used only by people who knows programming and can take responsibility in what they do. I love it because it does not come in between and let you do what you’d like to do; either good or bad.

    C# is designed to pull Java developers mainly emulating already familiar C/C++ syntaxes. It limits the language usage by taking care most of things [I personally don't require Garbage Collector] that normally is the responsibility of the coder himself. Also it has made the programmers lazy. But still it’s a good language.

    I am amazed by the way C++ still standing amidst all wanna be best languages. Even now, most of the high intensive applications uses C++ [AutoCad, Maya for example].

    So, if you are planning something that require to operate at hardware level as well as high level and cross-platform, then go for C++. Otherwise, it’s better you go to some managed languages.

  63. Comment by Eric | 2010/01/20 at 05:11:28

    I think C++ and C# both have their merits. Compared to C++, I think C# has features that can help a developer be more productive for many things, but C++ is still required in situations where you need to do more low-level tasks or tasks that are more speed-sensitive or timing-sensitive (somewhat analagous to writing in C++ vs. assembly code).

    Not long ago, I read that Microsoft may phase out Managed C++. Does anyone know if that’s true? I certainly hope not - Managed C++ provides the bridge from C#/.NET to C++ and legacy code. I imagine there are many useful libraries and pieces of code written in C++ that would not be accessible from C# were it not for Managed C++. Also, a company might have its own C/C++ codebase that it might want to re-use in C# (via Managed C++) rather than spending time (and money) re-writing it in C#.

  64. Comment by Yan Frieston | 2010/02/05 at 02:33:15

    Which is better in terms of massive scientific calculations? Please give help!

    Many thanks

  65. Comment by Eric | 2010/02/05 at 02:37:53

    For massive scientific calculations, I’m not sure either language would be better. However, one thing I think is nice about C# is that it includes a decimal numeric type, which does math in base-10 rather than base-2 so that you don’t get binary roundoff error. I know that numeric precision (i.e., significant figures) is important in doing scientific calculations, so that could be a plus for C#. There are base-10 numeric libraries available for C and C++, but some cost money and some can only be used in Linux or only on Windows, etc.

  66. Comment by Rhonald Moses | 2010/02/05 at 05:32:00

    For scientific calculations C++ will fare well; but FORTRAN is the best. You can actually build modules in FORTRAN and include them in C/C++.

  67. Comment by Bicubic | 2010/02/14 at 03:54:45

    I think most people who say they’re “done benchmarks” and found C# “x times slower” don’t actually work in the real world. Starting with the fact that neither C++ nor C# have any intrinsic speed. That’s determined by the libraries, the compiler and the architecture its compiling for.

    There’s only a small handful of real world scenarios in which these artificial benchmarks have even remote relevance to what you will actually be doing. Unless you’re writing quake 5 or a number crunching supercomputer client app, there aren’t many other cases where you will feel and perf loss between native and managed code. Funnily enough, C# is being trialed for cluster computing and has been found to have surprisingly little overhead.

    Getting back to the real world, most applications written are fairly lax on perf and heavy on gui and logic. Most businesses that write them focus on the best cost/benefit value and realize that writing managed code is considerably faster and more maintainable than something like C++.

    While working in the industry as a younger programmer, I found that many businesses still tend to avoid .net languages because their senior ‘old school’ programmers ‘hate’ the language without actually having written a single line of code in it. And I am very glad to see that as the number of younger programmers increases in the workplace, we are shifting that opinion towards objectivity and away from religious ‘i want to know what the cpu is doing’ crap. In 9 cases out of 10, C# is a better language choice for solutions in business, engineering, automation, media, data handling, etc applications; simply because you’re going to spend a fraction of dev time creating code to do the same things, if nothing else.

  68. Comment by Rhonald Moses | 2010/02/14 at 04:17:55

    Sorry mate! I don’t buy everything [except the part that benchmarks are waste]. Except Business; I don’t see C# being used ‘much’ in other fields and definitely not in Media [AutoCad, Maya all are in C++] and Engineering [C has upper hand here still].

    For Business and Business automation; yep C# has reasonable penetration. But when it comes to Web, PHP still rules the world dude.

  69. Comment by Eric | 2010/02/14 at 09:19:23

    In reply to Bicubic, I agree about the cost/benefit factors. As someone who has developed software in C++ for a while, C# seems better at letting the developer be more productive than C++. I’m also a younger developer who has been working in the industry, but not for too long.

    However, I think there are perfectly valid reasons why C++ would be chosen as a development language. I suppose one reason is actually why you wouldn’t want to choose C#: C# is a proprietary language, created by Microsoft, and Microsoft has no interest in developing a C# compiler and .NET runtime for platforms other than Windows. 3rd-party .NET implementations do exist for other platforms - the most prevalent being Mono - but Mono tends to be a step or two behind Microsoft’s implementation, and there is a chance that Microsoft could do something (legally or technologically) to impair 3rd-party implementations from being developed. This is in contrast to Java, where Sun develops the runtime for most platforms currently available. C++, on the other hand, is an open language, and compilers exist for almost all platforms.

    Also, I have heard that even in C#/.NET projects, C++ is used where performance is very important. C and C++ also seem more common on devices with limited RAM and storage space, although I’ve heard of C#/.NET for those devices as well.

    I suppose the thing that makes me hesitate most about C# is that it’s most strongly tied to Microsoft and Windows. If a company wants to develop software only for Windows, that’s fine, but sometimes it can be important to consider making your software available for other platforms as well too. That’s just another cost/benefit ratio to consider though: You have to consider your customers (or potential customers) and try to decide how much money the company could make by making the software just for Windows or also for Linux/Mac too.

  70. Comment by Savan | 2010/02/23 at 23:46:33

    :cool: :grin: :evil: :mrgreen: :neutral:

  71. Comment by Haridas Pal | 2010/03/09 at 12:40:29

    :mrgreen: :neutral: :twisted: :arrow: :shock: :smile: :???: :cool: :evil: :grin: :idea: :oops: :razz: :roll: :wink: :cry: :eek: :lol: :mad: :sad: :!: :? :

  72. Comment by marck_don | 2010/05/03 at 06:08:18

    Yes, I agree with nihangshah that you should start with C because then you can fairly easily progress onto any one of the C derivative languages, to name a few: C++ ,C# ,C– ,objective C, C++ .NET. C++ is probably the best as you can build apps for all platforms where as C# is only for windows, objective C for MAC apps etc.

  73. Comment by Vamp898 | 2010/05/27 at 19:06:04

    How to say. That is just nonsense

    I mean the talk about Programming Languages.

    Take a look at Google. On there Anrdoid stuff they use Java

    On there Web-Platform they use Python. Chrome OS/Chrome/Chromium is wirtten in C with GTK+

    Nokia uses C++ with Qt

    What do we see? The matter is not the Language. Its the guy who writes the language.

    Desktop Envirionments like KDE and GNOME even now turn to use JavaScript and also Windows (in case of his huge copy_from_other progress) starts to do so.

    Its not just “A Business will use C# becease they can develop faster with less problems” or something like that.

    And Desktop Environment works better if its written in C or C++

    Small fancy eye-candy games that you play for 5 Minutes to calm down in breaks are maybe better written in JavaScript

    btw. C# runs very very very good on Linux (http://www.mono-project.com/Compatibility) the GNOME Project uses more and more C# (Banshee, Tomboy, Beagle, F-Spot, GBrainy)

    With Mono you´re able to run C# Applications on Windows, Mac OS X (in case of that its just a cheap Unix system) and Linux

    Maybe C# is not a bad language at all but the performance boost you get with C++ is just too high

    http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=csharp&lang2=gpp

    if someone think it worths it…… why not

    But with toolkits like Qt, C++ is defenetly the better choice

  74. Comment by CATremblay | 2010/05/31 at 22:44:25

    Jim: No, what Dave is saying is that great power brings great responsibility. An f-16 is more difficult to safely fly than a go-cart. You are unlikely to, for example, accidentally destroy an apartment building with a go-cart, even if you have never used one before. Also, there are things can f-16 can do that a go-cart certainly can’t.

    More like soccer vs jet-pack-soccer.

    I don’t necessarily mean this as a reference to C# vs C++, I don’t know C# at all. But it works as an metaphor for other things such as DOS vs Linux. Where for one example, linux is more stable but there is no undelete.

  75. Comment by NoobFor9Years | 2010/06/21 at 13:41:24

    C# and C… I use them both…

    1. Coming from C++, I could say that C# is much better in my case. I am very productive using it. I could write apps faster than using C++. And I can deliver it to the client fast.
    2. Garbage collection is a big plus.
    3. Cross platform… Yes… I wrote a C# app and was able to use it in Opensuse Linux (Mono) w/o any recompilation… That’s a very very hugeeeeeeee plusssss….
    4. Speed… it always depends on the algorithm/flow created by the programmer… I have a case wherein my boss always told me that C# is a lot slow because it relies on .NET, they have their C++ app and boasting that I could never beat it’s fastness… It has lots of calculation + some hardware interactions. and after three days of development, we have a benchmark: their app takes 15seconds, and my C# app takes 1.3seconds… after that, I never heard a single word from them on that day :D :D :D

    Speed isn’t everything :)

  76. Comment by Vamp898 | 2010/06/21 at 14:19:10

    Sure if you´re an stupid programmer and have no knowledge of Memory Management you should better write good C# apps than bad C++ apps

    But you have to be a really bad programmer to write an C++ App that is slower than an C# app.

    And why not take the best from both? Vala for example have the same Syntax than C# but it doesn´t use .NET.

    The Source gets converted into C and then gets compile by your favourite C-Compiler (for me its GCC)

    So you have automated Memory management, easy syntax and all the other pussy stuff but still have the great speed

    http://live.gnome.org/Vala (also take a look at the Wikipedia article)

    And you can´t compare C++ with C# in every case. C# have a big library behind it named .NET with which you are much more productive than with ANSI C++

    But for example with Qt you can write C++ apps 1000x faster and with less code than with C# and .NET and you dont lose and ms of speed.

    So if someone really says he have to use C# becease of advantage XY than he just dont know how to compare (99% Windows users)

  77. Comment by Greg | 2010/06/25 at 15:40:27

    @Bicubic:

    I find your argument about ‘old school’ programmers amusing. I am one of the younger programmers where I work, but I started in computers very early. I tought myself a few languages and attended college where I learned others.

    I am open to new ideas. I work with other fresh minds and most of them are all about .NET and C#. Fact is, as I talk with them about languages and programming, it has become painfully obvious that they aren’t polished programmers. They do not know how to write tight code. They also seem to be clueless how to fully leverage C++. I blame poor teachers for this. My C++ teacher in college was terrible. IMO, most programming teachers teach like math teachers - unable to create a compelling real-world example of why you should use specific tools and why to use them a certain way.

    These C# proponents I work with have decent troubleshooting but not excellent. These are sharp guys with holes in their knowledge. Nothing personal to them or the other C# proponents, but C++ and the people that are skilled in it just seem to produce the best, fastest, most well though-out code. As someone else pointed out in this thread, C# is for beginner and intermediate programmers. IMO, it’s the programmers that are intermediate that think they are polished that seem to tout C# as the better language.

    While I am making a case, the argument about standard libraries doesn’t make sense to me. It makes sense if you reinvent the wheel over and over again. Any programmer is going to make a set of their own libraries they use from program to program. Even in C#. While one may spend some extra time initially building some libs to make C++ friendlier for quick programming, the end game for a decent programmer is similar productivity for new programs. As a for instance, if I am writing a new C++ program that interfaces with XML, I don’t code an XML class all over again. I use the one I already made. I’d rather have my C++ libs than C# without my libs.

    At the end of the day, there are too many technical things to do and not enough great programmers to go around. This argument ends up as academic. C# is here to stay and C++ is here to stay. Use the tool that matches your skill set + target hardware and enjoy bringing programs to life.

    -G

  78. Comment by Tikiwiki | 2010/06/26 at 01:29:41

    C# is the Java bitch of the future, it will take time for the world to think differently.

    Yessssss!

  79. Comment by renelda | 2010/07/25 at 15:25:13

    Anjuna Moon is an egotistical oaf at best.

  80. Comment by Joshed | 2010/07/29 at 02:36:48

    wow I can say that this thread can go on forever since opinion is an opinion. The person who loves C# will always defend it so as with C++.

    In my own point of view what suites you best is what you should use.

    whichever will make you succeed in your career will always be the best for you.

    Good luck to all :p


Trackbacks & Pingbacks »»

  1. Pingback by Jay L. T. Cornwall’s Personal Site | 2007/09/16 at 13:29:16

    [...] to suppress those concerns back then but after stumbling across a post on Michael Suess’s blog comparing features of C++ with C# I’ve had second thoughts. On that impulse I’ve decided to retarget my natural rendering 3D engine [...]

  2. Pingback by C# Resources for C++ Developers | oweynge | 2009/01/12 at 16:35:05

    [...] C++ vs. C# - a checklist from a C++ Programmers point of view by Michael Suess [...]

  3. Pingback by What is the difference between C# and C ? | Web Moments | 2009/11/21 at 18:38:35

    [...] http://www.thinkingparallel.com/2007/03/…|||there are many differences, in fact, too many to list. They really aren No Related Post [...]

Leave a Reply

HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>