This is the start of a new series of articles that I’m writing about C++ for Windows. I took some time off from my regular writing schedule to evaluate my approach to Windows programming and gain some actual production experience using the latest iteration of C++ in my new Micro ISV (check out Window Clippings). What I will be presenting here is not the C++ you’ll find in most of the sample code currently found on MSDN. This is not about MFC. This is not even about ATL and WTL that I’ve recommended for years. This is a fresh new approach to Windows programming with C++. I don’t claim that my ideas are unique but I have found in my experience that the techniques that I’ve adopted help improve my productivity and produce better quality code, code that is easier to maintain, more reliable, and helps to enable excellent performance.
With the introduction of Visual C++ 2010 back in April of this year there was an opportunity for me to reconsider the way I develop applications for Windows. One of the unique aspects of C++ is that it is a multi-paradigm programming language. Other programming languages require you to write all your code as classes, or all of it using only functions. They might provide a handful of container types that you’re practically forced to use. Alternatively they might not provide any and force you to write your own. C++ however places no such constraints on its users. Bjarne Stroustrup sums it up nicely:
C++ was designed to support data abstraction, object-oriented programming, and generic programming in addition to traditional C programming techniques … It was not meant to force one particular programming style upon all users.
As the C++ language and the compilers that implement it have evolved and improved over the years different approaches have been popularized for writing Windows programs. To better appreciate these different approaches it is useful to consider the difference between libraries and frameworks.
Using frameworks generally means that you plug in a bit of code into a larger framework to make your application run. Frameworks usually provide a large runtime or considerable infrastructure that you need to embrace in order to take advantage of the framework. Examples of frameworks commonly used to build Windows applications today include the .NET Framework and the older Microsoft Foundation Classes (MFC).
On the other hand using a library generally means that you write your application in whatever way makes sense to you and then plug in a bit of library code to solve a particular problem in your application without dramatically affecting the way your application is written or packaged. Examples of libraries commonly used in Windows applications today include the Active Template Library (ATL) and the Windows Template Library (WTL). Of course there are many others.
There isn’t always a very clear distinction between frameworks and libraries. You can for example use ATL in such a way that it effectively becomes a framework that your code plugs into. Some approaches or libraries might even exclude the use of other libraries. So while its multi-paradigm roots have helped C++ tremendously it has also inadvertently splintered the community of developers into different camps. Many developers cannot imagine using anything other than MFC to build Windows applications. Others swear by ATL and WTL as a more flexible and relatively modern approach.
I’m not here to tell you that any one of these approaches is wrong. That’s the beauty of C++. You get to choose what works for you and your application. I am here to tell you that Visual C++ 2010 provides the building blocks for a different approach that I’ve started using. An approach based on libraries rather than frameworks.
This series is called “The new C++ for the new Windows” because I’m going to show you how you can embrace C++0x, the unofficial new standard for the C++ programming language, and use it to your advantage when writing applications for the new Windows. The “new Windows” is just a cute way to refer to those new and improved libraries in the Windows SDK that target the contemporary versions of Windows namely Windows 7 and Windows Vista. That means I have the luxury of avoiding all that nasty code in existing libraries like MFC and ATL that uses older APIs dating back to Windows 95 when far better alternatives exist today.
And that’s it for my introduction. The first few parts of this series will lay down some foundational principles and then we’ll dig in and look at how they can be used with various parts of the Windows SDK. I’m hoping to publish one installment a week and I’d love to hear what you think.