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!

Reply to thread

Message: <blockquote data-quote="Ian Kaplan" data-source="post: 93465" data-attributes="member: 16310">Using C is inexcusable. Sure there are some narrow application areas, like heavily constrained embedded systems, where the use of C can be justified. For some embedded systems C++ compilers are unavailable or the code that they generate is unreliable. But in the vast majority of cases the use of C is inexcusable. Programmers who insist on using C when there are alternatives never really learned object oriented programming.Using C++ is very expensive. Any large C++ program will struggle with memory errors. Programmers are imperfect and their imperfections will eventually manifest as memory errors which are very difficult to locate and correct. Also, the software resources available for C++ are far smaller than those available for Java. Still, there are cases where C++ is the right choice. These situations are not that common, but they definitely exist. However, there is no reason to use C. What ever can be done in C can be done better in C++. By better I mean more maintainable and with fewer errors. C++ contains C as an almost complete subset. Any low level operation that can be done in C can be done in C++. But C++ gives the programmer the ability to structure code in a way that is clearer and more maintainable.The fact that people continue to use an ancient programming language is simply depressing. We would never design such a language today. Unconstrained pointers and a lack of range checking were justified by the limitations of computer hardware 40 years ago (e.g., the DEC PDP 10). These limitations are long gone. The module structure of C is equally antiquated compared to object structure. The very fact that anyone would even argue for using C (again, except in heavily constrained embedded systems) is iconic of what is wrong with software engineering in practice. This post should not be considered inflammatory but obvious.</blockquote>

Verification