• C++ Programming for Financial Engineering
    Highly recommended by thousands of MFE students. Covers essential C++ topics with applications to financial engineering. Learn more Join!
    Python for Finance with Intro to Data Science
    Gain practical understanding of Python to read, understand, and write professional Python code for your first day on the job. Learn more Join!
    An Intuition-Based Options Primer for FE
    Ideal for entry level positions interviews and graduate studies, specializing in options trading arbitrage and options valuation models. Learn more Join!

Why is C++ good for Quantitative Finance? Top 3 reasons

1. Fair tradeoff between speed and ease. Good programmer = good memory management speeds things up even more
2. Functional reusability. Team can split up work easily. Easier to handle for large projects
3. Standard

Don't know why ASM was even mentioned. It'll probably take a month to write a function that takes C++ 1 week to write.
 
From an outsider (my background is in Comp. Sci./Eng. and Applied Math) point of view, I was too somewhat surprised with the obsession with C++ among quants (well - among admittedly very limited sampling of quants that I was in touch with, although I seem to get the same impression from lightly tracking relevant forums, master program offerings, job posts, etc.). I find C++ an OK OO language, and if used very, very carefully, it could be even on par with Fortran/C for writing numerical codes (as nicely demonstrated by Eigen linear algebra library). But I find recent C++ trends, like insisting heavily on template meta-programming and that kind of stuff, completely wrong regarding both code readability (this stuff is much worse than assembly in that regard) and code efficiency. Unfortunately, seems like these trends are starting to dominate C++ world (Boost libraries, mentioned above, are an example of this - while there exist some good stuff in Boost, most of that what is good is actually already pulled into std::tr1, and the rest of it is utter garbage, worst crap that I've had to deal throughout my whole career as programmer), so people often resort to these techniques just because they are available and/or fashionable, resulting in messy and very un-efficient code. So I find OP question ("why is C++ good/advantageous for quantitative finance") very interesting too - except for the fact, mentioned in several replies, that most of the codes seem to be already written in C++ so it's natural choice for new codes (which is certainly valid reasoning), I'm still puzzled...
 
But I find recent C++ trends, like insisting heavily on template meta-programming and that kind of stuff,

Nuance is useful here. There are two levels of template programming

1. At application level (95% of the commmunity)
2. TMP (for compiler builders)

So, category 1 users (myself included) don't need to know TMP but to learn boost the template/generic way of thinking must be mastered. It's just another paradigm, like OOP. In some cases OOP has been used instead of GP with the resulting problems emerging.

Generic programming is becoming popular in C# as well.
 
C++ combines the best of both worlds for Quants (and any other profession heavily dependent on software to implement their ideas). Why? It combines the desing needs for OOD, the flexibility of C (which can be incorporated into C++ directly) and the longevity of many years experience of the real world. Is it the only language to use for Quant? Clearly not, there are others - but why move away from flexibility, maturity, speed when you don't need to? I don't see C++ moving off center stage anytime soon!


From an outsider (my background is in Comp. Sci./Eng. and Applied Math) point of view, I was too somewhat surprised with the obsession with C++ among quants (well - among admittedly very limited sampling of quants that I was in touch with, although I seem to get the same impression from lightly tracking relevant forums, master program offerings, job posts, etc.). I find C++ an OK OO language, and if used very, very carefully, it could be even on par with Fortran/C for writing numerical codes (as nicely demonstrated by Eigen linear algebra library). But I find recent C++ trends, like insisting heavily on template meta-programming and that kind of stuff, completely wrong regarding both code readability (this stuff is much worse than assembly in that regard) and code efficiency. Unfortunately, seems like these trends are starting to dominate C++ world (Boost libraries, mentioned above, are an example of this - while there exist some good stuff in Boost, most of that what is good is actually already pulled into std::tr1, and the rest of it is utter garbage, worst crap that I've had to deal throughout my whole career as programmer), so people often resort to these techniques just because they are available and/or fashionable, resulting in messy and very un-efficient code. So I find OP question ("why is C++ good/advantageous for quantitative finance") very interesting too - except for the fact, mentioned in several replies, that most of the codes seem to be already written in C++ so it's natural choice for new codes (which is certainly valid reasoning), I'm still puzzled...
 
(In my opinion) One reason why C++ is good for everyone, not just QF. It is a widespread and fast language. You can take another widespread language such as Java, but it is far too slow. On the other hand, Fortran 90/95 is a very fast language, but it is not used a lot outside of... really just the physics field. In finance, anywhere it is still being used, C++ is making its way in.
 
To me, a core issue is that C++ does what you tell it, Java et al do what they think is best.
 
Another reason why C++ is good - following from Dominic's comment that C++ does what it tells you - is that it allows me to create multi-dimensional applications precisely for the reason that you can control the memory.

In the 90's the trend was to garbage collection (Java) but if you have a 5-factor PDE then I seriously doubt if it will work properly in Java (apart from the fact of doing maths in Java is a mismatch for me), for example creating tensors of size 200^5. Many applications just crash while it is possible (just about) in C++ even under 32 bits OS.

So, a perceived advantage of automated memory management is a possible bottleneck in future applications. Java is not my area, but I wonder even if C# can handle these large data structures.

---------- Post added at 03:41 PM ---------- Previous post was at 03:27 PM ----------
But I find recent C++ trends, like insisting heavily on template meta-programming and that kind of stuff, completely wrong regarding both code readability (this stuff is much worse than assembly in that regard) and code efficiency.

Unfortunately, seems like these trends are starting to dominate C++ world (Boost libraries, mentioned above, are an example of this - while there exist some good stuff in Boost, most of that what is good is actually already pulled into std::tr1, and the rest of it is utter garbage, worst crap that I've had to deal throughout my whole career as programmer), so people often resort to these techniques just because they are available and/or fashionable, resulting in messy and very un-efficient code. So I find OP question ("why is C++ good/advantageous for quantitative finance") very interesting too - except for the fact, mentioned in several replies, that most of the codes seem to be already written in C++ so it's natural choice for new codes (which is certainly valid reasoning), I'm still puzzled...


1. tr1 contains parts of boost and not all that much (read the documents)
2. boost libraries are the most professioanl I have seen in C++ (me a 1989 veteran of C++)
3. What about all the maths/stats/multi_array/uBLAS/Function/Random/Special functions etc. These are exactly the libraries that quants need and use. And there are many more useful ones.
4. I grant you that the documentation is sparse in general and you need to know templates very well to understand the code
5. Most quants do NOT need to learn boost MPL!

(6. C# is suitable for applications as well, but this is proabably off-topic)


I have some 101 examples on boost here that try to make it a bit more accessible because it does take time to reverse a lot of the functionality.

http://www.datasimfinancial.com/forum/viewtopic.php?t=111

I find C++ an OK OO language
That's only 33 1/3% !! You can also do generic AND modular programming in C++

I don't see any language equaling C++ in computational power in the next few years. But that is not to say that other languages will not become more popular.

hth
 
Let me qualify: one of the criticims against C++ in the recent past was that you had to do all your own memory management and having automatic garbage collection was a major plus.
Nowadays C++ has smart pointers as well as manual memory management.
 
Why is Python being neglected from the discussion? It has some incredible libraries, is immensely fast to develop in and code maintenance is straightforward due to excellent readability.

One may question the performance of Python code against C++, but NumPy/SciPy optimisations (such as those outlined here PerformancePython - ) and the proposed implementation of Unladen Swallow into the 3.x branch will have Python code becoming comparable to C speed.

A bigger topic is whether performance is as important as many make out for the vast majority of financial applications.
 
This is what I saw in Willmott. Indeed, it is a very interesting and important question.

Dr. Duffy's answer is:
1. C++ is highly flexible an interoparable with everything on the planet.
2. Mature: supports multi-paradigm development.
3. It is an ISO standard (this means it will be around forever).

To me, the answers are quite abstract and general. It seems that this can also be the answer to "Why is C++ good? "

My top three are:
1. C++ provides encapsulation which makes program more stable and readable.
2. C++ promotes code reusability and is a good language for very big and complex projects which is needed to be worked by a team.
3. If you know C++, others will assume you are knowledgeable....

I think my understanding may be too mediocre and hope others can provide opinions on this issue. The other thing is I still dont see anything specific reason related to quantitative finance. Does anyone have a better understanding?
Having done some studies in (The theory of) Programming Languages I can tell you most academics do not like C++. C++ was the first language taught to me and I use it day-to-day.

1. C++ provides encapsulation which makes program more stable and readable.
I dont' think C++ is readable. Many would agree.
2. C++ promotes code reusability and is a good language for very big and complex projects which is needed to be worked by a team.
I rather code a complex system with, say, Java than C++.
3. If you know C++, others will assume you are knowledgeable....
Somewhat true.

I think the real reason is because of raw speed. See these two posts

Azul Systems - Cliff Click Jr.’s Blog
Cliff Click Jr.’s Blog:Java vs C performance... again...

Cliff Click is a well informed, to say the least, and he is authoritative.

Dr. Cliff Click
Chief JVM Architect of Azul Systems
With more than twenty-five years experience developing compilers, Cliff serves as Azul Systems' Chief JVM Architect. Cliff joined Azul in 2002 from Sun Microsystems where he was the architect and lead developer of the HotSpot Server Compiler, a technology that has delivered dramatic improvements in Java performance since its inception.


---------- Post added at 10:37 AM ---------- Previous post was at 10:19 AM ----------

Pascal is and was a shit language ...
Please refrain from using obscene language. Perhaps, you should go look at what innovative features it introduced. The designer of Pascal - Niklaus Wirth - won a Turing Award.

---------- Post added at 10:47 AM ---------- Previous post was at 10:37 AM ----------

Why is Python being neglected from the discussion? It has some incredible libraries, is immensely fast to develop in and code maintenance is straightforward due to excellent readability.

One may question the performance of Python code against C++, but NumPy/SciPy optimisations (such as those outlined here PerformancePython - ) and the proposed implementation of Unladen Swallow into the 3.x branch will have Python code becoming comparable to C speed.

A bigger topic is whether performance is as important as many make out for the vast majority of financial applications.

PEP 3146 -- Merging Unladen Swallow into CPython - Merging Unladen Swallow into CPython

Performance Retrospective

Our initial goal for Unladen Swallow was a 5x performance improvement over CPython 2.6. We did not hit that, nor to put it bluntly, even come close. Why did the project not hit that goal, and can an LLVM-based JIT ever hit that goal?
You'll find that performance critical code is still written in C.

My main issue is the global interpreter lock: jessenoller.com - Python Threads and the Global Interpreter Lock

There's also Guido van Rossum who seems misunderstand Tail Calls: http://flyingfrogblog.blogspot.com/2009/04/when-celebrity-programmers-attack-guido.html.

---------- Post added at 10:50 AM ---------- Previous post was at 10:47 AM ----------

To me, a core issue is that C++ does what you tell it, Java et al do what they think is best.
Please explain what you mean.
 
Well, different folk have different experiences (whether it be first-hand or you can accept the word of someone else). Fine by me.
But why do Java folk have such a hang-up about C++? I find it very amusing and a bit sad.

I dont' think C++ is readable. Many would agree.
This is a weak argument. You can made C++ as readable or unreadable as you like. Reminds me of the story of the tradesman and his tools; he was always blaming them.

I think the real reason is because of raw speed
Nope. Read my comments 1-3 below. But C++ is fast as well :)
 
I think the real reason is because of raw speed
Nope. Read my comments 1-3 below. But C++ is fast as well :)

If execution speed is the only criteria, then don't use any OOP language.

An STL container that can handle generic object types will not offer same performance (memory/access time etc) as a finely tuned custom C collection of structures. A boost smart pointer, will never have the same access time as a raw pointer.

I can agree that C++ offers plenty of tools for performance optimization but it's always a tradeoff between performance vs maintenance cost. So, as C++ "supporter", I respect the richness that allows to move anywhere on this scale. In last years, Java has made a lot of progress with real-time concepts ...
 
It depends how OOP is used determines the performance. Apart from this, it is not always the best paradigm for computational finance; modular and generic models are more suitable.

If execution speed is the only criteria, then don't use any OOP language.
It never is the only criterion, in general.

A boost smart pointer, will never have the same access time as a raw pointer.
Yes and no. Do we build for speed or reliability? A rule is 1) don't optimise and 2) don't optimise yet(and then experts do it)
 
C++ combines the best of both worlds for Quants (and any other profession heavily dependent on software to implement their ideas). Why? It combines the desing needs for OOD, the flexibility of C (which can be incorporated into C++ directly) and the longevity of many years experience of the real world. Is it the only language to use for Quant? Clearly not, there are others - but why move away from flexibility, maturity, speed when you don't need to? I don't see C++ moving off center stage anytime soon!

Although I probably sound like a broken record by now, if speed is not the primary concern, then other languages provide a much more rapid development cycle and libraries that "just work". C++ is sometimes a sledgehammer to crack a wallnut.
 
Although I probably sound like a broken record by now, if speed is not the primary concern, then other languages provide a much more rapid development cycle and libraries that "just work". C++ is sometimes a sledgehammer to crack a wallnut.

Not yet, although saying these things with 200 posts under your belt it might be a bit OTC :-\" This topic have been discussed ad nauseum already.

There are many interdepedent concerns when choosing a language and the interaction can be nonlinear (you may or may not remember the Betamax versus VHS era).
 
This question is old but still relevant. Having not formally worked in a quant shop I can't say what it is like but I have read many accounts so all my evidence is in the 2nd person. My opinion is that C++ is heavily taught in school so the labor pool is more abundant. Additionally C++ offers speed comparable to C which is obviously a requirement in the financial industry or else Java would be more prevalent. But mainly I think C++ allows a quant shop to divide it's labor into two camps, the programmers and the modelers. With C++ it's the programmers job to 'abstract away' all the detail of the code and reduce it down to objects that modelers can use. Modelers are then able to focus more exclusively on their solution or model rather than the code itself. So I may even go as far as saying that the ominous use of C++ in quant shops is simply the product of how colleges churn out students. Students usually elect one major and very rarely do students dual major in finance and computer science, so the pool of dually talented professionals is limited. As a result the quant manager will fill two different positions as opposed to one. Another opinion of mine is that if there were more dual major graduates to hire from then maybe C will be the language of choice in quant shops since it is faster and simpler in many ways. Although C++ is multi-paradigm it's central features are it's OO features. Personally I think the OO paradigm does very little good in the quant world beside my reason mentioned above. How do you reasonably portray quant models or financial concepts as objects? It seems the desire to use an OO approach adds more complexity than it solves when the real goal of quants is focus on the markets.
 
I am not experienced enough . But I feel newer systems are being developed in Java more because the development time is much lesser. You have so many libraries and inherent support for almost eveything. The exception catching mechanism is amazing in Java. Once we tried using C++ for a part, the development time was high. Trying to develop distributed system was also not at all easy.
 
Back
Top