* 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?

“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.

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…

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.

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.

Regards,
Leo