December 6, 2005
-
C++ .NET, Java, and C#
I was drooling over the new Visual C# 2005 Express IDE that Microsoft released to the public for free. Apart from the usual goodness (IntelliSense) of its predecessor, Visual Studio .NET 2003, this new IDE also comes with improved refactoring abilities and is much easier on system resource – it does, after all, nothing but C#, as opposed to all the .NET languages that VS.NET2003 did. This is exactly what I want today. I don’t want to hear about C++, or Visual Basic, or J#. I just want a clean, kosher C# development environment. Ever since I have tried to work with managed C++ (i.e. Visual C++ .NET) over a year ago in a team project, I have decided that it’s not worth the effort to continue using C++. C++, since its early days, has been a dirty hack to add some object-oriented programming support to C. As though that was not bad enough, Microsoft made managed C++ even dirtier. For some strange reason that continues to evade me, the engineers at Microsoft decided to implement the .NET framework class library in a completely incoherent way for C++: while some classes are to be declared as objects directly, others are declared as pointers. All good OOP programmer knows that pointers are not welcome in the OOP paradigm because they are too troublesome to manage; beside, what is the point of using pointers when objects can be passed around freely? In the end, my whole team decided that managed C++ is a total disgrace and all of us sweared to not touch it again.
I never got a chance to like Java because I’ve been working with JSP and servlet technology only. All of my friends agree that the JSP and servlet technology sucks when it comes to configuration and deployment. I often have nightmares about the XML configuration files and the stupid .classpath file. I shiver and get cold sweat from the sheer thought of them. There are also other aspects of Java that I don’t like (the great typesafe enum that was missing until version 1.5, and the double meaning of the “static” keyword).
Finally, C# caught my attention. I figured that the compiler design course, which is programming-intensive, was a good opportunity to learn a new language. I picked C# because it sounds like a very promising language. Even without the fantastic .NET framework class library, the C# language is so clean syntax- and semantic-wise that it deserves attention in itself. This week, however, I encountered some strange quirk and I hope it’s just a bad implementation of the new C# compiler.
Somehow, it seems absolutely legal to declare method parameters to have the same name as a class member. The following code snippet illustrates my point…
public class foo
{
public int count;
/* Constructor(s), more fields, and more methods go here. */
public void doSomething(int count)
{
System.Console.WriteLine(count.ToString());
// Here, the method uses the "count" field instead of the
// "count" parameter.
}
}An application that uses the above class will compile, run, and give you unexpected output. The compiler gives neither error nor warning. I skimmed through the C# specifications and have yet to spot any detail about the resolution of name conflicts between parameters and class members. In any case, I hope that Microsoft intended to regard this kind of name conflict as outright errors, and release a corrected version of the compiler soon.
- SwordAngel
