The Pit of Success

  • Article

The Pit of Success: in stark contrast to a summit, a peak, or a journey across a desert to find victory through many trials and surprises, we want our customers to simply fall into winning practices by using our platform and frameworks. To the extent that we make it easy to get into trouble we fail.

- by Rico Mariani

In my self-introduction, I mentioned my past experience on developing ATL, CRT, MFC and STL. I've learned a lot from this experience, and as I work with people who develop services based on .NET platform, there are many interesting findings. Each time I stepped back and looked at things that have been developed, the more I love the "The Pit of Success" concept brought up by Rico Mariani. So here I'm trying to share some of my personal understanding.

ATL (not including ATL Server) is my personal favorite library for the following reasons:

  • ATL is a library instead of framework
    • in order to adopt ATL you don't have to change any existing architecture
  • ATL is lightweight
    • in most cases you can just use ATL header files, without dealing with *.lib files and DLLs
    • ATL won't bloat the binary size too much
    • ATL won't harm performance for sure
  • ATL is predictable
    • debugging through ATL source is straightforward
    • the main purpose of ATL is to make COM programming easier in C++, not to hide the complexity of the operating system concepts
    • the COM wrapper has a very clear definition on the thread safety

CRT is the library from which I learned a lot:

  • CRT acts as a bridge between the operating system and most applications
    • dealing with application startup and cleanup
    • providing runtime services (e.g. backing C++ exception scope with SEH and exception filters)
    • balancing between the underlying system implementation and the C/C++ standard specification
  • CRT has evil contracts with C++ compiler toolchain
  • CRT is not only consumed by normal applications, but also by operating system and compiler toolchain (which sounds like an infinite loop)
  • CRT always sits in the frontline of supporting new hardware architecture
  • CRT needs to be the most stable and compatible library

MFC is a framework consisting of class libraries:

  • it's easy to get started with MFC
  • MFC takes care of window management, messaging, COM and many great things
  • you really need to understand MFC in order to use it well, especially when you run into bug hell

STL is a C++ template library, which I've used extensively (in combination with Boost) when I was in school, when I developed STL and when I have good reason to use STL:

  • if I have a free choice, normally I would tend not to use STL
  • debugging template code is not easy, especially the code that makes extensive use of template meta-programming and macro meta-programming
  • running code coverage analysis against template code is tricky (source line coverage is almost meaningless, you have to use basic block coverage)
  • it's bad idea to pass (e.g. parameter, exception) STL objects across module boundary, since the underlying contract (e.g. object layout) might be different
  • binary size might bloat and turn into a serious problem