Viele der heute gängigen Programmiersprachen folgen dem objektorientierten Paradigma. In Anleitungen wurde das früher häufiger als »Nachrichten senden« erklärt, und mich hat das mehr verwirrt als es geholfen hätte.
In academic software development I have seen one software suite which was known to be hard to compile. I was tasked to do try it, and ended up writing a 1200 line Bash script which took care of all the edge cases.
Python doesn't have variables. It sounds mind-boggling, as one seems to use them all along. But really, that is not how it works with Python. This will really confuse people with a background in C or C++. If we do int n in C++, and write n = 1, n += 1 or the like, the address &n will never change. The value changes.
One of the danger of C-style arrays is that their length is not attached to the pointer that points to their beginning. This means that there are lots of unsafe library functions that might write beyond the allocated space.
I usually program C++ with Vim. Here is a list of handy plug-ins and auxiliary tools that I use.
There is a rather simple problem that sometimes is asked in job interviews:
The numerical software that I work with is written as command line tools. As such, they get their parameters from command line arguments and/or parameter files. Their output is written to files as well. Since one can redirect standard output into a text file, we will only consider files here.
The other day I saw some code C which I thought to be clearly wrong:
Pure functions only depend on their arguments and do not have any side effects (global variables, file I/O, ...). Their return value is completely determined by their arguments. If a function is expensive to compute and the argument space is small, it makes sense to cache the results to only compute them once in a program.
The GNU Scientific Library is a C library that offers (among other things) an
integration routine. One does not pass a simple double (*f)(double) function
parameter because there might be additional parameters needed. The article
Currying in C lists various possibilities, the GSL
implements the variant with the void *. A dummy implementation of this
integration routine could look like this, for the purpose of this article:
There is a great article about the learning curve of C++ stating that there are two types of people who claim to know C++: The first type has knowledge of C and superficial knowledge of C++'s classes and considers themselves an expert in C++ because there is nothing more to it. The second type has gone through the valley of frustrations and knows most of the quirks of the language.
I want to have a nice poster of a Mandelbrot set, say 75×50 cm². At 300 DPI printing resolution, I need to compute a lot of pixels:
Visualizations can be really great. They can quickly demonstrate a concept which we can understand much faster than trying to grasp it from words. The majority of people probably thinks visually at lot of the time. This is not the case for all problems or people, of course, as this quote from Lagrange shows:
This is a list of C++ anti-patterns that I have seen in various codes.
When you have an array with some data structure that you would like to sort, you are looking for a sorting algorithm in the standard library.
The error messages of compilers are in general a bit hard to understand. This is even worse with C++ because it allows for complex meta-programming and various other things.
I enjoy watching conference talks about programming. There are some very good speakers who really make informative and enjoyable keynotes. Here are some of my favorites.
There are a couple ways to measure the real (wall) time that some part of the
code has used. I know the standard clock() from time.h and all the chrono
from C++11. Then MPI and OpenMP have their own routines as well.
Currying is not part of the C language. A few alternatives are shown that
can be used: Global variables, GCC extensions, code duplication, void
pointers, variable argument lists, and general parameter structs. Also
C++03 and C++11 examples are given.
Someone said that using pow(x, 2) is always more inefficient than using
x * x. Well, there are two things to remember: