Scientific programming

Shaman introduction to C++

by Nikolai V. Shokhirev

Work in progress

ABC tutorials

Up: Scientific programming
Previous: Numerical objects
Next: Project environment

Introduction

You are a professional, a specialist in your area of expertise. For some reason you have to program in C++. You are not a "C++ guru". However, you already have a huge advantage over any computer scientist or guru: you know what to program. C++, Fortran, Matlab, etc. are just tools in your professional toolset. You simply want to use these tools effectively, probably without knowing all "bells and whistles".

C++ has its specifics. It is a combination of a low-level procedural C, its object-oriented extension, generic (template) extension, and the STL. The polite way to express this is: "C++ is a federation of languages" ^[1]. The combined grammar is complicated. C++ is error-prone. Its grammar allows doing a lot of stupid things.

Below I collected some rules that help with writing scientific programs in C++. Some of them are actually required by the language, the others are just a good programming practice. I present them without much explanation on a shaman level ^[2]:

I prefer the term "shamanism" because this is not a high-level doctrine such as Cargo cult programming ^[3] or Voodoo programming ^[4]. The rules are not strict as Commandments ^[5] or Taboo ^[6]. For example, "Do not use" should be read "Avoid using". I also do not go so far as in ^[7].

Shaman's spells (in a random order):

Stick with one language of the "federation": e.g. switch to pure C if you do not need the rest or do not use C-specific features in C++.
Do not use pointer arithmetic
Do not use multiple inheritance
Do not use any "#define" directives. Use const and enum instead.
Do not use global variables.
Don't write a copy constructor if shallow copies are OK. If the object has no pointers to dynamically allocated memory, a shallow copy is probably sufficient.
If you need a copy constructor, you also need a destructor and operator = .
Polymorphic base class (which has virtual functions) should have a virtual destructor.

In a constructor, prefer member initialization list to initialization inside the constructor:

   Solver::Solver(int n, int m): grid(n, m), x(n)  // initialization of user-defined objects; match declaration order
   {
      SetDefaults(); //  initialization of built-in types
   }

Do not use assignment inside a condition:
```
   if (x = y) {
   ...
```