Dangers of C++

Recently I had a strange bug that caused a previously working C++ simulation to fail. It turned out that a logically unrelated portion of code was corrupting the memory and that corruption resulted in changing of parameter values which resulted in instability. Corruption was due to writing out of index. If that index pointed to a memory location outside the boundaries of my program I would get an access violation. Unfortunately, indices were pointing to my programs memory, therefore I did not get any errors from the operating system and had to pin point the bug by trial and error, i.e. commenting out sections of code until I got a stable state and then uncommenting until I got instability. A simplified version of the code:

Simulink: Generating code without model version and date

When you generate code with Simulink, the generated header and source files will have model version and date in code comments. This results in version changes in your version control system even when you have not changed any logic. In order to avoid unnecessary version updates, you should comment out the "Model version" and "C/C++ source code generated on" sections in the ert_code_template.cgt file (Configuration Parameters > Code Generation > Templates > Code Templates).

Dangerous while loop

Today a program I am writing stopped responding. After some debugging effort, I came across a 3rd party function that limited an input angle to the [-180, 180] degrees interval. It was using a while loop to increment or decrement the angle. Unfortunately, I was passing an uninitialized variable to it and its value was -9.2...e+61. Such a large value would take years for the function to limit. Below is the original function constrainAngleWhile(), together with much better alternatives:

What does valgrind's "still reachable" message mean?

When I check my programs with valgrind for memory leaks I usually get a "still reachable" result, even if there is no memory leak. An example valgrind output:

HEAP SUMMARY:

    in use at exit: 72,704 bytes in 1 blocks

   total heap usage: 3 allocs, 2 frees, 74,752 bytes allocated

72,704 bytes in 1 blocks are still reachable in loss record 1 of 1

…

LEAK SUMMARY:

   definitely lost: 0 bytes in 0 blocks

   indirectly lost: 0 bytes in 0 blocks

   possibly lost: 0 bytes in 0 blocks

   still reachable: 72,704 bytes in 1 blocks

On valgrind's doc it says: "still reachable" means your program is probably ok -- it didn't free some memory it could have. This is quite common and often reasonable.

I wrote a simple program:

#include <iostream>

int main() {

    return 0;

}

After I compile and check it with valgrind I get "still reachable". If I comment out the #include line, I don't get "still reachable". I have to research a little bit more.

C++ "already defined" error

One of the most frustrating errors that a beginner C++ developer faces is the "already defined" linker error. Below is an example that can cause that error and its three solutions:

For more information, see include, inline and static keywords.

GitHub: Go back to a previous commit

 You can see commit history by clicking the commits link:

You copy the SHA of the commit you want to revert to, open a terminal, go to source folder and type

git reset --hard <SHA>

C++: Dynamically create array of objects

Dynamically creating array of object on the heap:

MyClass** objects;

arrSize = 100;

objects = new MyClass*[arrSize]; //Note the '*' before arrSize

for (size_t i = 0; i < arrSize; i++) {

objects[i] = new MyClass();

}

Freeing up heap memory allocated to object array:

for (size_t i = 0; i < arrSize; i++) {

delete objects[i];

}

delete[] objects;

Tip: You can use Visual Studio's Memory Usage diagnostic tool to check heap memory changes which gives clues about memory leaks. To get the function names where memory is allocated but then never released, use valgrind on WSL (Linux) as follows:

valgrind --tool=memcheck --leak-check=yes ./<app name>