[om-list] Why use C# instead of C/C++?

[Mark Butler]

Why use C# instead of C/C++? (Tom asks)

The answer to this is essentially the same as why one would choose Java over C++.  The general rule is to always use the highest level language that provides satisfactory performance and stability.  Despite some of the problems I mentioned, Java now nearly dominates the custom high-end business software market, where C++ never has and never will, because it is much too low level of a language - easily twice as expensive to develop in as a language like Java.  The advantages of low level optimzation are significant if you are writing performance critical software like real time graphics applications, or are developing software whose costs will be amortized over millions of copies.  The disadvantages come because low level languages require programmers to handle many issues that higher level languages handle automatically, which makes a big difference in the RAD world.  You don't see many
web applications written in C++, for example - higher level languages dominate.

Specific disadvantages of C/C++ over Java or C#:

1. C and C++ are fundamentally unsafe without serious attention to array and buffer overflow conditions.  Most C/C++ network services (web servers, DNS servers, etc.) have been discovered to be vulnerable to remote security compromises at some point. On Unix, the BIND name server had several last year, on Windows, Microsoft IIS had several this year - both weaknesses allowing full system compromises on unpatched systems (e.g. Code Red).  In both cases, we are just lucky that the exploits were relatively benign - they could have easily destroyed the target systems.   C and C++ programs also tend to leak memory and crash due to pointer problems - Java and C# solve both problems with integrated garbage collection.

2. The C++ concept of inheritance is implementation inheritance, rather than interface (semantic) inheritance.  This is a big deal when you are operating with several different implementations of even something trivial like a string type (C string, basic_string, CString, etc.) and you are forced to manually convert back and forth all the time.  Implementation inheritance is a disaster for large scale systems development, because simple implementation changes force massive recompilation.  Interface inheritance (as used in Java, C#, CORBA and COM) solves that problem very nicely.

3. The C++ binary interface is very fragile, generally varying from compiler to compiler (name mangling differences), and requiring updates whenever attributes and virtual member functions are added to base classes.  This nearly cripples the use of C++ to develop operating systems and shared libraries, an area the C (the lingua franca of language development) does very well in due to its interface stability. That is why there are no successful C++ operating systems, by the way. There are whole books dedicated to handling these problems in large development projects.

4. Java and C# both define an extensive set of standard libraries that implement critical functionality that the current standard C++ library doesn't even mention. In particular: multithreading, locking, interprocess communication, and network access.  The absence of a standard for such libraries is why real world C++ projects are rarely compatible with each other on a code level.  Instead you end up with N factorial different dialects according to your choice of libraries.  Code written in MFC is dreadfully non-portable and completely incompatible with code written in every other application framework, even discounting user interface code - if you need to merge two such code bases into the same program, you can guarantee that one of them will need to be completely rewritten.  Due to library standardization, this is not nearly as serious a problem with Java and C# programs. 

5. C++ does not support an extremely powerful feature called introspection, which allows Java and C# programs to lookup and enumerate object methods and attributes by name.  While not horribly efficient, this is extremely useful for object libraries that implement persistence (database storage) and serialization (network communication).  C++ requires that you write no end of code that explicitly marshals each attribute from one format to another, which gets to be a serious maintenance problem. On my last major C++ application, if I added a new configuration attribute, I had to make changes to at least seven different modules.  Introspection can dramatically reduce this requirement.

6. For several reasons C++ does not (and cannot) have a clean interface to most modern distributed object systems, in particular SOAP, COM and CORBA.  C# allows you to access SOAP & COM objects in other processes on other machines as if they were local variables.  Similar code in C++ is exceedingly ugly. This will be the number one reason for rapid C# uptake in the Microsoft world - Until now everyone has been forced to use Visual Basic(!) to get the same advantages.   Java has similar capabilities, but lags behind C# in transparent XML RPC support, a very critical technology for electronic commerce and other Internet scale integration.

7. Finally, both C# and Java are distributed in forms that are processor architecture and operating system independent.  For high end commercial closed source software, this is a major advantage.  Most leading edge technology companies would rather die than let their customers look at their source code. An OS/processor neutral software distribution format keeps them from having to port to half a dozen different platforms and also allows customers to run software on platforms that vendors do not explicitly support.  Although Microsoft C# will support a lot of Microsoft capabilities not generally available on other platforms (e.g. COM/MTS/ADO/ASP), most C# assemblies will be as portable as Java class files, to any platform with a C# virtual machine.

 - Mark