After a long hiatus, I'm back programming in C++. It turns out that I didn't miss it. I used to be really into becomming a better C++ programmer, read the newsgroups , the journals, the books by the gurus - Herb, Andrei, Bjarne, etc. and loved it. I've spent the last two and a half years programming in other languges, first Tcl/Tk, then C#. I give the Tcl experience mixed reviews, maybe I'll write more about that in another post, but I loved my C# experience. Going back to C++ was more painful than I expected. Some things you can go back to and they seem easy, some things you go back to and they seem hard. I also found that my programming style in C++ has changed, and probably for the better. So what don't I like about C++ anymore:
1. Syntax. C# seems to have a nice unified syntax. You create an object, you call new for everything. Calling new for value types seemed wierd at first, but now seems natural. The syntax for casts are plain ugly (I know that's partly by design, you should strive not to use them, but sometimes real life gets in the way). I don't like the scope resolution operator (::).
2. Resource Management. I miss garbage collection in C#. More and more I tend to avoid dynamic memory in C++ as much as possible but there's more resources to worry about. I also have to keep looking up the obscure rules like what you cannot do in DLLMain() (which makes cleaning up singletons interesting. It's painful to have to go back writing a constructor, destructor, copy constructor, assingment operator, and usually a Swap function as well.
3. Multiple overlapping libraries. One of my favourite things about .NET is the rich library that comes with it. Nice as the STL is, the main parts I use are the collection classes, the filestreams, and the string class. In my current C++ project I need an XML parser, so I'm using MSXML. This of course introduces COM types. So in my (relatively small) code base, I've got C strings (char*), C++ std::string, BSTR, _bstr_t, and since I'm using NUnit to test my C++ DLL (there's a reason I didn't use cppunit that I won't get into) I'm also dealing with managed strings. Each string has a different interface, and I have to deal with each one. It gets complicated! Also, for my needs I required a round function to convert a float to an integer. .NET has a nice Math.Round method that always "rounds to even". There is no standard round funciton in the C or C++ libraries that I could find. A number of times I found myself writing code that I would prefer to just reuse.
4. GUI programming. Part of the problem is the design of MFC. The bigger problem is that I need more lines of code to make a simple dialog.
5. Exception handling. Making C++ code correct in the face of exceptions usually means using RAII. I had to write a few of my own little classes to release my resources. I do like the try/finally in C#, or even better the using statement. I find that it improves the locality of the code (is that a real quality?). I also like the very dynamic aspect of the laguage, where all exceptions derive from a common base class. In my C++ code, I don't want any exceptions propagating beyound my DLL boundary so I ended up adding a catch(...) clause, which just makes me feel dirty.
That said, for my task I still think C++ was the right choice. I'm providing a DLL that is to be used by applications that do not depend on .NET, and the customers would be rather unhappy about (would not accept) having to suck in a big dependency just to get our functionality. I would still rather program in C#.
