Thoughts on C#
01 May 2004
I've been programming in C# for the past few weeks at work, and I wanted to record some of my thoughts. It's a well designed language overall, and the .NET Framework has been a useful library. If only the IDE wasn't a constant source of frustration and anger.
Here, then, are some of the main differences between C# and C++ (the language I know best).
- C# is a higher level, interpreted language. In C++, you play tricks with your data structures by reading and writing their memory directly, using pointers. In C#, these are replaced by reflection, a more powerful, but slower, method of instantiating runtime-typed objects or retrieving a listing of an object's methods or fields. My C# code loads a lot of objects from strings in configuration files, making it easier to change my program's behavior without recompiling. It can also help separate infrastructure code from application logic.
- C# has garbage collection but makes it difficult to deterministically despose of objects or resources. This means I don't have to worry (much) about memory leaks, but I could easily avoid them in C++ by using a smart pointer like boost's shared_ptr. The lack of C++ style destructors is a pain, though there's some good reasoning behind it. (Remember, there's nothing in C++ to stop you from returning a pointer to a local variable.) I still haven't found a use for the finalize method, since you can't seem to assume anything about the program's state when it's called, but the Dispose method and using directive are a useful substitute (and an interesting mix of language keywords and specific classes; more on this below).
- C# sometimes conflates the underlying language with your code. Certain keywords act on particular interfaces, as in the example above and foreach with the IEnumerable interface. Also, the compiler automatically generates certain methods, like Begin- and EndInvoke on delegates. This is very convenient but feels improper. C++ does a bit of this with operator overloading, but C# goes far beyond thet.
There are more differences, but I'd rather talk about the problems with C#. Here's a partial list.
- The documentation sucks. It's impossible to find useful information among all the crap about DirectX, COM, and the N other technologies you don't use. When you do find the class or function you care about, it doesn't tell you what you need to know, or else it's wrong. For example, TcpClient.Close() doesn't disconnect your socket, contrary to its description (you have to use TcpClient.GetStream().Close() instead). And Thread.Abort() doesn't kill the thread it's called on (it throws an exception in the thread that called it). And many classes are described only as “internal to the .NET Framework”, including useful things like the IXmlSerializable interface that lets you customize the XML serialization of a class. And you have to follow extra links to find out basic information, like the namespace of a class or the parameters of a function. And the Longhorn documentation crashes Internet Explorer (but then, so does Microsoft Project). And so on. It's inexcusable.
- The lack of flexibility of certain classes. The System.Configuration includes some convenient classes for reading from a configuration file, as long as you don't need to specify the file. In fact, .NET's configuration works badly in general, and doesn't even do the one thing it's supposed to: allow your program to always find its settings. Another restrictive class is RemotingConfiguration. Channels cannot be unloaded, and Configure can only be called once. Apparently, the recommended way to stop listening on a port (with remoting) is to restart your process.
- The string.Format function. It may be less kludgy than C++'s strean operators, but it's also a return to the days of C's unchecked function parameters. In this case, the runtime stops you from mangling you memory, but will happily throw exceptions at very inconvient times. C++'s output routines can generally be verified by the compiler, an important safeguard.
I have a few other minor quibbles with C#, but its flaws pale in comparison to those of Visual Studio. I don't understand how the same company can create such a well-done language and such a poor tool for using it. It's an insult to the designers of C# and those of us trying to use it. But don't worry, as we say at work with each newly-discovered or re-encoutered flaw, it'll all be better in Longhorn.
168 Comment(s)