- It gives access to many of the facilities previously available only in C++, while retaining some of the simplicity to learn of VB.
- It has been designed specifically with the .NET framework in mind, and hence is very well structured for writing code that will be compiled for .NET.
Where Does C# Fit In?In programming language terms, if you start from the lowest level of language available to Windows developer and move up, you'd see something like this:
» Assembly Language
» C, C++
» C#, J++
» VBA, scripting languages
As you move down the list you get to languages that are considered progressively easier to learn and quicker to develop code in, but which leads to less efficient code. Thus, assembly language will give you absolute top-performance code, but it's so hard to write and debug that you'll only really find it used in things like selected subroutines in some high-performance games, and some software that controls hardware devices where performance is critical. For most applications requiring good performance, C++ has traditionally been the language of choice, while if you're developing GUI applications and want them written quickly, you'll probably opt for VB. Performance isn't really important for GUI applications because the limiting factor tends to be how fast the user can click the mouse!
C# is designed to fill a perceived gap between VB and C++. It's aimed at developers who would like to be able to write code more easily than is possible with C++, but without the overhead of VB. (A gap that J++ seems to have largely failed to satisfy - although it has to be said that there are a lot of similarities between C# and J++). C# has a syntax that is very similar to C++, and supports many C++ language features, for example inheritance (though not multiple inheritance) of classes. For this reason C++ programmers are likely to find C# easy to learn. By contrast, I suspect for VB programmers, it's likely to be only marginally easier to learn C# than to learn C++. C# is also heavily integrated into COM: C# classes are automatically COM objects. (If you don't want that overhead, you can declare your class as a struct instead).
A good example of the way C# steers a middle ground between C++ and VB is on the question of memory management. In VB, the only memory management you ever need to do is remember to Set your objects to Nothing when you've finished with them - and the only penalty if you forget to do this is system resources and memory may be used for slightly longer than necessary. On the other hand, C++ not only gives developers the chance to fine tune exactly what variables occupy memory for how long (thus potentially leading to highly efficient memory usage) - it largely requires them to do so. Which means C++ programs are prone to memory management bugs, often leading to memory leaks, in a way that can't really happen in VB.
C# mostly takes the VB path on memory management - the language itself takes responsibility for handling it. But unlike VB, in C# if you want to sort out the memory yourself, you can opt to do so by declaring a section of your code as 'unsafe', and then allocating and deallocating memory in the same way as is done in C++.