C++ Programming: C# comparison with C++
We already covered Java. C# is very similar, in that it takes the basic operators and style of C++ but forces programs to be type safe, in that it executes the code in a controlled sandbox called the virtual machine. As such, all code must be encapsulated inside an object, among other things. C# provides many additions to facilitate interaction with Microsoft's Windows, COM, and Visual Basic. C# is a ECMA and ISO standard.
C# was a response from Microsoft to the (then Sun-developed) Java language that was beginning to have a major impact in the enterprise. After their failed attempt to push J++ into the market and in legal confrontation with Sun, Microsoft shifted their focus to managed languages, even as a way to maintain the relevance of Virtual Basic with a large developer base, and so with the announcement of Windows "Longhorn" project (which became Windows Vista) the push to managed languages and its integration with the Windows Operating System began, with the belief that from there on "all new Windows APIs would be managed".
Today however, Microsoft seems to have finally realized that managed languages, even looking on the adoption of Java, lack the requirements to develop an Operating System. Microsoft even started a C#-based OS to test the premise, but came to a realization that all major software projects, even utilities that come with the Windows OS, are mostly C or C++ based. Even if managed code still has a place, C and C++ have finally been accepted as the core languages of the software industry for the foreseeable future. In Windows, this is being seen as the "C++ Renaissance" after the long age of darkness that the marketing machine had engulfed developers with.
- Issues C# vs C++
- Limitation: With C#, features like multiple inheritance from classes (C# implements a different approach called Multiple Implementation, where a class can implement more than one interface), declaring objects on the stack, deterministic destruction (allowing RAII) and allowing default arguments as function parameters (in C# versions < 4.0) will not be available.
- Performance (speed and size): Applications built in C# may not perform as well when compared with native C++. C# has an intrusive garbage collector, reference tracking and other overheads with some of the framework services. The .NET framework alone has a big runtime footprint (~30 Mb of memory), and requires that several versions of the framework be installed.
- Flexibility: Due to the dependency on the .NET framework, operating system level functionality (system level APIs) is buffered by a generic set of functions that will reduce some freedoms.
- Runtime Redistribution: Programs need to be distributed with the .NET framework (pre-Windows XP or non-Windows machines), similar to the issue with the Java language, with all the normal upgrade requirements attached.
- Portability: The .NET complete framework is only available on the Windows OS, but there are open-source versions that provide most of the core functionality, that also support the GNU-Linux OS, like MONO and Portable.NET http://getdotgnu.com/pnet. There are ECMA and ISO .NET standards for example for C# and the CLI extension to C++.
There are several shortcomings to C++ that are resolved in C#. One of the more subtle ones is the use of reference variables as function arguments. When a code maintainer is looking at C++ source code, if a called function is declared in a header somewhere, the immediate code does not provide any indication that an argument to a function is passed as a non-const reference. An argument passed by reference could be changed after calling the function whereas an argument passed by value or passed as const cannot be changed. A maintainer unfamiliar with the function and looking for the location of an unexpected value change of a variable would additionally need to examine the header file for the function in order to determine whether or not that function could have changed the value of the variable. C# insists that the ref keyword be placed in the function call (in addition to the function declaration), thereby cluing the maintainer in that the value could be changed by the function.