Fog Creek Software
Discussion Board

Windows C++ Development

There are a few different choices available for developing native Windows applications in C++. For example:
  - MFC
  - ATL / WTL (although WTL is unsupported)
  - Custom wrappers around win32 (depending on the size and scope of the project obviously)

Note that I'm not asking about Delphi, VB, .NET, etc. I'm specifically interested in starting a thread about Windows and C++.

Personally, I like to style my own code using modern C++ idioms as written about by Meyers, Lippman, Sutter, etc. I like to take heavy advantage of the STL and generic programming; I know that OOP is not a panacea, and that other valid design techniques exist.

MFC was architected before the C++ standard existed, and before templates and the STL were defined, let alone popularly used. Understandably, it doesn't "fit in" with the aforementioned development style.

ATL and WTL,  on the other hand, make heavy use of these modern techniques. Unfortunately, ATL's scope is very tightly defined, and unless paired with WTL falls short of being a general Windows development library. WTL, from what I've seen of it, is very nice. As I mentioned, however, it lacks any official support, and documentation is quite sparse.

My questions follow:

What do you recommend? What have you used?

What does Microsoft do internally? What does the Office codebase look like for example?

What about companies like Adobe? From the looks of Photoshop, it uses a custom GUI toolkit. What's it like?

What are some good resources that can answer questions in this space?

Do you have any related advice or insight?

I realize these questions are quite broad. I think it's healthy to model yourself after those who have found success with their techniques, and so I will be intently reading your comments.

Thanks a lot!

Tuesday, November 26, 2002

I use both ATL and MFC for building the GUI portion of the application.

I tend to do the main GUI part of the application in MFC. I generally restrict my use ATL for writing COM objects and some library code.

This is not my personal preference (I love the power of ATL would happily do most of the application in it) but I find that MFC is easier for people following me to maintain and understand.

Where possible (and it not always is) I try to split the application internally into the GUI and Logic portions. The actual logic functions I tend to write in std C++ (STL etc). I try to avoid using MFC collections and other non-GUI MFC objects as their STL counterparts are generally superior. Where I have to use both I designate an interface point of the application where I translate all the MFC objects (e.g. CString) to/from their STL counterpart ( std::basic_string<> ).

I have not used WTL but would be really interested in having a look at it based on what I have heard from others.

Tuesday, November 26, 2002

At my work, we support Windows and Mac. We use MFC and maintain our own inhouse Mac port of MFC for our cross-platform code.

Tuesday, November 26, 2002

We use Borland C++ Builder. It has a few quirks, but at least you don't have to deal with a filthy mess of preprocessor macro trickery as in MFC, and to some extent ATL. There's a recent thread on Builder in this very forum.

Andrew Simmons
Tuesday, November 26, 2002

I don't understand your desire to avoid WTL. You say it's unsupported, but so would any wrapper library you write. It's white box (all source is included), so you can fix any bugs you find.

In short, why is that a big issue?


Brad (The .NET Guy)
Tuesday, November 26, 2002

Have you considered QT toolkit ? It is written in clean C++ and works on many GUI.

Tuesday, November 26, 2002

Or a high-performance, lightweight, cross platform, GUI library?

check [ ] -  FLTK strikes an amazing balance between usability and complexity. And it's also extremely fast.

Ori Berger
Wednesday, November 27, 2002

"[ ] -  FLTK strikes an amazing balance between usability and complexity. And it's also extremely fast."

The latter is not something that can be said for the website ATM. I gave up on waiting for a response :(

Thursday, November 28, 2002

FLTK is really nice for many kinds of GUI apps, especially small and simple ones. It has no Microsoft heritage (in fact it is a port of an X11 toolkit), which is both a good thing (no ingrained "bad habits") and a bad thing (less compatibility with other Windows code).

However, my experience with cross-platform toolkits (I've used GTK, Qt, FLTK, and Tcl so far) is that they tend not to be able to take maximum advantage of any one they support.

I have recently come to the conclusion that it is not really possible to handle a large GUI system in "pure" C++. Specifically, the memory management issues are so complex that you will inevitably have to design a reference-counting system, if not a full garbage collector. Of course these can be done in C++, but once you take these steps I think you are already most of the way towards a custom scripting language. You might as well pick up an existing scripting language which has already been designed and debugged, and gain the advantage of skpping compile time. (I have quite a bit of experience using a "pure" STL/boost form of C++; the long compile/link times were a killer).

When I say "scripting language" I don't only mean the usual suspects like Python/WxWindows or Tcl/Tk; there are also nice forms-based tools like VB and GTK's libglade.

Anyway, sorry for getting off-topic. I know you are set on straight C++ but I think it's important to note that it's not 100% suitable for GUI work, at least without significant memory management infrastructure. (it's a corollary to the old saying, "Any sufficiently complicated C program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common
Lisp." - replace "C program" with "GUI application" and "Common Lisp" with "Visual Basic" :)

Dan Maas
Monday, December 2, 2002

Oops - I should add that in addition to handling memory management you are also going to have to come up with an event model. In C++ you are going to end up using one of three things:

1) an ad-hoc type-unsafe event system based on C function pointers (cf GTK, raw Win32)
2) a type-safe but inflexible and non-extensible event system based on virtual functions (FLTK)
3) a type-safe and extensible event system based on either a signal/slot library like libsigc++ (GTK--) or preprocessor tricks (Qt)

This is an important decision because it dictates how much control you have over event handling and how much type-safety you can put in the code. (event handling order is very important if you do any computations that take a non-negligble amount of time, and a lack of type-safety is going to lead to the obvious mistakes)

Dan Maas
Monday, December 2, 2002

*  Recent Topics

*  Fog Creek Home