I have one (minor) gripe and one point of praise for C# today.
First the gripe. I really do not like having to declare a single
static class member named Main as an entry point to my program. It is more than a little distracting especially now when I am working with small example programs. This won't be such a big deal to me once I start producing 'real' programs in C#. My solution has been a simple re-write to isolate the class with Main in it, but the real question was what to name that class. I wanted to make it perfectly clear that the class did not matter. Turns out that _ is a perfectly valid class name in C#:
using System;
class _ {
static void Main ( ) {
Console.WriteLine ("Hello World!");
}
}
I told you it was minor.
Now the praise. Delegates, Interfaces and many other mechanisms in C# can be done in C++ but in C# they are raised to first class parts of the language. Making them first class parts of the language has its pros and cons. C++ approaches this with the philosophy of not restricting the end user into a single solution, and it succeeds in following this philosophy. Callbacks can be implemented in many different ways in C++, just look at this site for the options available. But this list also highlights the problem: I will in the end choose just one of those solutions. If library A uses callback library A` and library B uses callback library B` then when I go to build an application using libary A and B I could end up with a real mess on my hands. In C# while the Delegate implementation may be sub-optimal for some types of applications I can rest assured it will work across all the libraries I use. So C# and C++ take different approaches, and given the target audience of each language they both made the right choice with C++ leaving things possible but not standardized vs C# raising those concepts to first class parts of the languge.