It is important at this stage for me to put on record that my first C++ book (2004) is for those who already know C++ while the new one (2006) (you can see it in the Wilmott bestseller list) is for those who have not (necessarily knowedge of C++ (also no C assumed). I would hope that the latter is a A-Z. The 2 books complement each other.

This is an important distinction and potenial readers should be aware of this.

These books are in the Wilmott bookshop.

C++ is one of the most popular languages for the development of software systems for Quantitative Finance. It is more than 25 years old and it supports the modular, object-oriented paradigm (OOP) and the generic paradigm (GP) in the form of C++ template functions and classes. Most developers are familiar with OOP but a smaller percentage of these developers use C++ templates to design and implement efficient, portable and robust software. There are a number of reasons for this situation some of which are that the syntax of C++ templating can be difficult to understand and second the idea of designing software components using C++ has not been given full justice in the literature. Using templates to design components is similar to how hardware is designed. For example, think about the hardware ports on your laptop; it provides services to other hardware entities and it requires services from other hardware entities. In a similar vein, we are designing the Monte Carlo engine based on similar principles; it consists of a number of plug and socket components. For example, an SDE component provides a set of interfaces for defining and accessing the mathematical description of a stochastic differential equation. It requires data and parameters from a GUI screen, database system and real-time data feed systems. Continuing, a component ‘FDM’ that approximates the solution of a stochastic differential equation requires the services from SDE and provides services such as discrete paths and other statistics to other components, for example an Excel application. In this sense we build large applications using interoperable building blocks. This idea is called policy-based design using C++ templates.

C# - as well as other object-oriented languages such as C++ – is a descendent of the C programming language (K&R 1988). It is worthwhile to pause and consider whether it is better (in some sense) to develop new applications in C# or C++ (incidentally, it is possible to create .NET applications using a combination of C# and C++ but this topic is outside of the current ‘blog’). In order to help the reader determine how to choose between C# and C++ we discuss the problem from three perspectives:

P1: The skills and knowledge of those engineers developing QF applications P2: The type of application and related customer wishes P3: The technical, organizational risks involved when we choose a given language

We discuss each perspective in turn. First, C++ is a huge multi-paradigm language and it supports the modular, object-oriented and generic programming models. It is based on the C language and it would seem that it is the language of choice for many pricing, hedging and risk applications. It is not an easy language to learn; we liken it to a beast that must be tamed and cajoled. Furthermore, even though there are many books that discuss C++ and its syntax there are surprisingly very few books that discuss how to apply C++ to QF. To this end, one of the authors (Daniel J. Duffy) has written two books that fill this gap (see Duffy 2004, Duffy 2006). C#, on the other hand is a relatively new language and it supports the object-oriented and generic programming models, but not the modular programming model. This implies that everything must be an object or class in C# which may not be to everyone’s liking. Not everything is, or needs to be an object. In general, C# is much easier to learn than C++. It shields the developer from many of the low-level syntax that we see in C++, in particular the dreaded pointer mechanism, memory management and garbage collection. In short, the C# developer does not have to worry about these details because they are automatically taken care of by the garbage collector. This is a mixed blessing in general because there are situations where we wish to have full control of an object’s lifecycle. It is surprising to us that C++ is not in more widespread use in the universities and places of learning given the fact that many of the investment banks in the City, Wall Street and other financial centres throughout the world may explicitly ask for C++ experience from potential employees. C++ is a vendor-neutral language (it is an ISO standard) while C# was originally developed by Microsoft for its Windows operating system. We now discuss perspective P2. This perspective is concerned with the range of applications that C++ or C# can be applied to, how appropriate they are to these applications and how customer wants and needs determine which language will be most suitable in a particular context. In general, customers wish to have applications that perform well, are easy to use and easy to extend. On the issue of performance, C++ tends to be more efficient than C# and tests have shown that C++ applications are 20% faster than the corresponding applications in C# in general. This difference may or may not be a critical factor in determining whether C++ is more suitable than C# in a particular context. We now compare the two languages from the perspective of developer productivity. In order to answer this question we need to define what we are measuring. C# has many libraries that the developer can use, thus enhancing productivity. C++, on the other hand does not have such libraries and they must be purchased as third-party software products. In particular, user-interface software for C# is particularly easy to use while in C++ the developer must use libraries such as MFC or OWL, for example. In general, we conclude that productivity levels are much higher in C# than in C++. In some cases we have seen a three-fold productivity gain, all things being taken into account. Finally, perspective P3 is concerned with the consequences and risks to the organization after a choice has been made for a particular language. C++ is a large and difficult language, it takes some time to master and C++ applications tend to be complex and difficult to maintain. By the way, this latter problem is not the fault of C++ but it is caused by bottom-up programming mentality and a premature implementation before a proper design was carried out. On the other hand, C++ will be with us forever and this implies that C++ code that works now will still function in 20 years time. With C# the situation is different. It is restricted to the Windows platform (in principle) and it may be superseded by some other language in the future. Of course, it may evolve into a language that will be embraced by both Linux and Windows programmers alike. Time will tell. To paraphrase James Joyce, we could say that “C++ has a great future behind it” and it will be up to the C# community to prove that C# is a viable alternative to C++ for QF applications. This is what we attempt to show in this book.

These two gentlemen are members of the Wilmott community but can anyone guess who they are?

Hint: one is a football fan of a London club (not Chelsea) and the other's avatar looks like a Blues Brother?

One has written a book and the other is in the process of writing a book.

THE FIRST PERSON WHO KNOWS WINS A PRIZE.