NoShame,Here is my 2 cents on C# and C++. Hope this helps. //QuoteC++ 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.

QuoteEclipse + CDT? J++ died a miserable death because people realised MS tried to release a proprietary form of the Java language which wasn't portable -> defeating the whole purpose of the language. The IDE had nothing to do with it. What IDE do people developing C++ on Linux (KDE etc) use?This is incorrect. J++ died a premature death largely because of legal issues. When it was released, many people were keen to use J++ even without the platform independence of Java, as it provided a more elegant Win32 GUI language than VB.

Thank you Master.By the way, I believe C# will do the job well if it is more productive and efficiency.I think it is about adoption by the QF community. With due respect, I think the current generationof QF community are more C++ base. However, I believe C# has the future. I did my assignmentswith C++ and C#, I like C#....hey I know DCFC will tell me...C++ will get interview.QuoteOriginally posted by: CuchulainnNoShame,Here is my 2 cents on C# and C++. Hope this helps. //QuoteC++ 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.

It seems this discussion is going in circles. I also feel a bias towards C++ (especially its windows cousins) by most of posters here. Allow me to try to change this discussion around and ask what exactly is the future that we are debating? Are we trying to predict what a sophisticated Quant from a dark and stinky cubicle of some private wealth management boutique or a hedge fund will use in, let us say, 10 years? If this is what we are debating than I would agree with most of the posts here... i.e. yes, he will probably use the same C++ (or its derivative) as he uses today to cook up some impressive algorithms for his superior. But if the future is 1 bullion of new global internet users of which over 100 millions are potentially greedy investors in global markets, than I would disagree with most posts here. The question of the future in this case will be: How quickly an investor (or a money manager for that mater) can react to changes in global market, people perception of economy, evolving technology and regulations?In 10 years the number of global investors will at least quadruple. The perception of software and user experiences will evolve beyond our imagination. So will our Quant still crank up his C++ code in his dark and stinky cubicle?In other words can you really build and deploy a sophisticated and scalable quantitative application using only C++/C# and deliver it to the masses in shortest possible period of time?So what is the future of the future in question?

Quote With due respect, I think the current generation of QF community are more C++ base. However, I believe C# has the future. I did my assignments with C++ and C#, Have you tried C++/CLI in this context? Then a choice between C# and C++ is now superfluous.C++/CLI Design Rationale

Yes, but C++/CLI is clunky (i.e) you have to write more code then the c# version. However if you have to mix and match between C++ and C++/CLI then yes a definite bonus.Can C++/CLI run on other platforms then windows, is they a mono version at all?

QuoteOriginally posted by: martinlukerbrownYes, but C++/CLI is clunky (i.e) you have to write more code then the c# version. However if you have to mix and match between C++ and C++/CLI then yes a definite bonus.Can C++/CLI run on other platforms then windows, is they a mono version at all?It's not perfect I admit but it beats using MFC!I always get nervous when I hear about MS tools being developed on (li)UNIX. Once upon a time Software AG was developing COM on Sun Sparc stations... It's not a sound business model.