First Exposure to C#...

I used Microsoft's Visual C# for the first time, and no, it is not the Visual C# Express Beta that was recently released.

To be honest, there are features in the language that I loved, features that I hated, and in many regards, I am surprised to see how similar it is to C++. For example, a feature that I really loved was the using scope used to state exactly when the destruction occurs. For example, to read from a file, the code is essentially:

try {
 using ( System.IO.StreamReader reader = new System.IO.StreamReader( fileName ) ) {
    ior = reader.ReadLine();
 }
} catch ( Exception e ) {
   System.Console.Error.WriteLine( fileName + " raised an exception: " + e.Message );
   System.Environment.Exit( 1 );
}

This certainly is more impressive than the Java code to do the same, and you are certain that an object destruction will occur. Java needs one of these.

A feature that I found a little too C++ish was the derivation of classes. Instead of Java's class Subclass extends Superclass, C# uses class Subclass : Superclass; Instead of Java's class Class implements Iface for interfaces, C# uses class Class : Iface. This could have been better.

The IDE, however, was really nicely done with both superclasses and interfaces, in that you simply press TAB after the name, and it automatically adds the interface for you. I have not used the Visual C++ extensively, so perhaps it does this also. One thing it lacks, however, is the Make Clean feature that Visual C++ has.

Coming from Java, I expected the ToString method of each class to do something a little more meaningful than tell me the class's package and name, though. Similar to Java, however, the C# does not have default values; that's OK.

An interesting feature which both Java and C++ does not have is a switch statement that cannot fall through. If you forget a break before the next case, the compiler provides an error. I can think of algorithms that will need some rewriting, and although there are ways around it (such as using a goto), I think that this is mostly a good feature.

One thing that was neat was the ref keyboard, which states that a parameter to a function is a reference. This reference in the calling function can be reassigned, similar to a return value. The caller of the function, however, needs to place the ref keyboard before the parameter, which I find very useful. In C++, there have been many places where looking at the code quickly, you do not know if a parameter is modified within the function or not, so this was nice. On the Java side also, I found this feature interesting, because you could pass in an object, and the object could be reassigned underneath, whereas in Java, you would need a mutable class.

Included with my purchase of the Standard edition was Getting Started with Microsoft Visual C#.NET Version 2003. It was nice to look through, but I really found it lacking for experienced developers. For example, when I wanted to know how to create a subclass, I went to the index and, there is nothing on deriving or subclassing. Perhaps this would be OK for someone who has never used a programming language, but I was not really impressed by it.

Of another gripe, I really did not like the MSDN help. Sure, it gives you a lot of examples, but it does not talk about very much. For example, the Socket documentation does not really say much, and methods like Bind also say very little and its Exception documentation is a flaky at best (“...use the SocketException.ErrorCode to obtain the specific error code”). In this regard, I find the JavaDocs much more verbose and helpful.

One feature of that I learned from the aforementioned book was about checked and unchecked expressions. Essentially, the checked block will check for integral arithmetic operations and conversions that can wrap, which will throw an exception if it does occur, and unchecked will not check for wrapping. Of course, this begs the question of what the default is, which is unchecked. Interesting. Of course, it made me wonder why they actually implemented an unchecked, so my first attempt to understand it was to nest a checked in an unchecked scope; of course, it uses the scope nearest to the overflow... To add to the curiosity, if you call a function in an checked scope, that function is not checked! Another thing that is not checked is floats, even it you divide by 0! In this case, the variable becomes infinity.

And speaking of exceptions, I am happy to see that C# requires exceptions to be derived by the same base class (Exception or a subclass of it) and that it implements a finally clause in the spirit of Java, but what about Exception specification and requiring exceptions to be caught or forwarded? Any function that you write can throw an exception anywhere, and you have no idea what exception will be raised, nor will you know what potential exception. There are many people in the C++ world do not like the exception specification, due to the way that it is implemented. Specifically, if you specify that the class will raise a SocketException exception, and it raises an Exception, this is considered grounds for crashing. In Java, the compiler would catch this. I am concerned that people will not pay attention to exceptions, and it will become as problematic as adding exceptions to a legacy C++ application. I suppose that the reason that they have done this is to follow the dream of "type in any language," so it had to be at the lowest common denominator. This is unfortunate.

I did not do a lot of development, but of what I created, I found the class library to be mostly comparable to Java's. However, when I went to create a Multicast class comparable to Java's MulticastSocket, I started to use UdpClient class, but where is the method to set the timeout? Well, I googled over this for a bit, and this class has a few issues. Not only can you not set a timeout, but you can get corrupted data. As a result, you have to develop your own multicast class.

The namespaces are more like a C++'s namespace than a Java package. On a stylistic factor, the domain name-based namespaces would probably have fewer conflicts with competitors. I am not a huge fan of all methods and classes starting with a capital letter, but again, I guess this is following tradition.

On the security front, my WinXP box has some access to some Samba drives; the security manager is very protective of what I can and cannot run on these drives. I agree that some security is required, but I think that this particular restriction seems may have major drawbacks in some corporate environments.

My first limited impression of C# is that it has some good points, but it could have been and should have been more. Of course, I am not yet an expert or even well versed in C#, so take any of this will a grain of salt, and I will probably take some of this back in the future :-).