Vinícius Miranda

First Rule : If have no interest in deeply investigating the nuances of a highly complex language, think twice before choosing C++ .

The learning curve of C++ is very high and the syntax sugar the language offers can be highly dangerous if not use appropriately. For numerical work, FORTRAN 90 is still unbeatable. Even if you don't like FORTRAN, C can do a perfect job.

Second Rule : If you are self confident about your C++ skills, you probably overestimate your C++ understanding .

The language is so complex that years of dedicated work is necessary to understand all its concepts. If you are bored, try solving some of the C++ Guru of the Week puzzles.

Third Rule : If you are crazy enought to learn C++, follow google style strictly until you master their forbidden rules .

Don't rush. Be simple. std::exceptions and RAII are powerfull techniques but they can cause serious problems if used without knowledge. It takes time and effort to master them. After that, however, you will see that RAII can help you manage memory allocated by C libraries, like GSL-GNU.

Fourth Rule : Don't blindly trust C++ numerical libraries just because they are open source.

The failure of expression templates on BLAS level 3 operations, a technique that respected open source libraries are based on, is a good example. Rule of thumb: If you can buy NAG C libraries, do it now! Otherwise, try one of the libs that are shown on the right panel.

Fifth Rule : Never write or use C++ libraries to the heavy numerical duty .

Use GSL-GNU or NAG-C library instead. In extreme cases, if you need to consult Numerical Recipes, choose the free C version. Example: boost is a very good library, but boost::ublas handles matrix multiplication poorly because it is based on expression templates. Another example: if you store some data that will be used in inner loops in a std::vector container, you should pass the underlying C-array to an previously compiled C code using the std::vector::data(). You could also write yourself the inner loops using std::vector::iterator, which is nothing more than a pure C pointer, instead of the [] operator. This will be enough to help compiler to activate Single Instruction Multiple Data (SIMD) optimization, a powerful technique available in modern processors.

Sixth Rule : Don't blindly trust in C++ wrappers .

With simple tricks, mix C libraries in C++ is possible and easy! For example, the official C++ wrapper of CFITSIO seems to be heavily based on std::valarray and std::auto_ptr (std::auto_ptr is deprecated and std::valarray is not well designed) and that is a bad implementation decision! Another example: GSL wrappers must use static functions to implement gsl_function. This can make the wrapper to not be thread safe. Same for GSL memory management. To avoid race condition, each thread must have a private allocated gsl_workspace and it is hard to control that directly using wrappers!

Seventh Rule : Always use the pointer "this" when you refer to member variables or member functions .

Remember: Many people don't know about google naming convention and probably won't read it just to be able to understand what you are doing. Once at work, a C programmer had difficulty to identify where my variables were defined. And he is right! Member variables do look like global variables! By using the pointer "this" you are saying that this variable is part of a "struct" (the C analogous of a c++ class). If you are working with a lot of C coders, I suggest an approach even more clear. Instead of using member functions, you could use friend global functions that take a pointer of your class as input. This is exactly what C coders do when they want to mimic C++ classes and they will understand it without problems.

Eighth Rule : If you have a piece of code that can be easily generalize to be used by more than one class, write it in a global function .

When we learn C++, our first impulse is to write everything in member functions. However, member functions are tied to a particular class and, consequently, if another class needs similar behavior, you will face the problem of copying/paste 100 lines of code that needs only small changes to be used again. In the end, your program tend to be unnecessary big. Remember: smaller code are easier to update, maintain and debug. So even if you have just 5-10 lines of code that you can generalize to avoid repetition - do it! This will increase the level of indirection but will make your code simpler and more elegant.

Final Rule : Why use C++?

Except hardcore programmers, I believe most people like some syntatic sugar, otherwise we would all be playing with assembly language. However, benchamarks like CLBG usually shows that whatever high level language you prefer is too slow. The only exception is C++. Also note that benchmark codes are usually much better in quality than your average code. So, if C++ takes 11s and Python 18min to solve a simple N body, you should expect longer waitings in your work. Last, but not least, C++ is the only high level language with enormous support from intel. Intel compilers, math and parallelization libraries and can boost your code speed significantly.

Remember :

Do not expect C++ to be faster than C/Fortran, because high level code can never surpass the efficiency of a close to the metal language. Although this sometimes happens, it is not the purpose I suggest for choosing C++. However, if your code is slower than C/Fortran by more than 50%, then you should rethink your design. To begin with, you could use C++ only when you need to put lots of heavy duty C code together in a big coherent project. Actually, I like to think C++ as a good management language, where the objected oriented abstraction can be very helpful. One quick look in GSL/CFITSIO source code shows that it is cumbersome to reproduce this kind of design using pure ANSI-C.