Asserts in constexpr functions

Assertions (like C-style macro assert) are not an ideal, but still useful tool for indicating assumptions about program correctness, and help finding programmer bugs. In this post we will see how we can use assertions in constexpr functions. This works different in C++11 and C++14. Continue reading

Posted in programming | Tagged , , , , | 8 Comments

The GCC bug affects you

This is a follow-up to my previous post about a bug in GCC. I was reading comments, and observed that some readers say that the example I used is rare, or artificial, or that it does not follow “good programming practices”. I want to give you another example. Continue reading

Posted in programming | Tagged , , | 7 Comments

A serious bug in GCC

This post is to inform you about a bug in GCC that may cause memory (or other resource) leaks in your valid C++ programs. Continue reading

Posted in programming | Tagged , | 21 Comments

Toggles in functions

Have you ever seen a function call like this?

process(true, false);

We are processing something: this should be clear from the context. But what do these parameters mean? What is true and what is false? From the function call we will never figure it out. The code surely isn’t self explanatory.

We will have to stop, and take a look at the declaration, and it does give us a hint:

void process(bool withValidation,
             bool withNewEngine);

Apparently, the author of the function uses the two bools as toggles. The implementation will probably be something like this:

void process(bool withValidation,
             bool withNewEngine)
{
  if (withValidation)  // toggle #1 used
    validate();

  do_something_toggle_independent_1();

  if (withNewEngine)   // toggle #2 used
    do_something_new(); 
  else
    do_something_old();

  do_something_toggle_independent_2();
}

From the author’s point of view, or the function’s definition point of view, there is no problem with readability, because each toggle has a name assigned to it. The problem occurs only on the side of the caller. Continue reading

Posted in programming | Tagged , , | 31 Comments

(Not) detecting bugs

The following code contains a bug. A developer has spent quite some time looking for the source. The intent of this code is to iterate over two vectors simultaneously, from the first up to the one-before-last element. Thus the most interesting tools that will be employed will be boost::zip_iterator and std::prev.

#include <boost/iterator/zip_iterator.hpp>
#include <boost/tuple/tuple.hpp>
#include <vector>

using zip_iter = boost::zip_iterator< 
                   boost::tuple<
                     std::vector<int>::iterator,
                     std::vector<int>::iterator
                   >
                 >;
int main()
{
  std::vector<int> v1 = {1, 2, 3, 4, 0};
  std::vector<int> v2 = {2, 3, 5, 7, 0};
    
  zip_iter beg {boost::make_tuple(v1.begin(), v2.begin())};
  zip_iter end {boost::make_tuple(v1.end(), v2.end())};
  
  auto process = [](zip_iter::reference){};
  std::for_each(beg, std::prev(end), process);
}

The purpose of a zip iterator is to iterate over a number of containers at the same time. It takes a tuple of iterators, each iterating over a different collection, and upon each dereference it returns a tuple of references: each reference to an element form the corresponding container.

I have simplified the program to the minimum. I am using GCC 5.3. This code compiles fine, but when I run it, it goes on and on. In this post we will see where the bug is, but more importantly, we will look at why this bug has not been detected during the compilation, and wasted a fair deal of the developer’s time. Continue reading

Posted in programming | Tagged , , , , | 3 Comments

More const — fewer bugs

I have just read article “Please declare your variables as const” by Bartłomiej Filipek. It argues that declaring your variables const is beneficial for reasons other than performance. In particular, it can help find bugs in your code. Now, let me illustrate this claim by showing how the const could help find the bug from my previous post. Continue reading

Posted in programming | Tagged , , | 9 Comments

Concealing bugs

Consider the following piece of program code.

void process_names()
{
  const char * fileName = "contents.txt";
  const char * foundName = 0; // will be assigned to later
  
  Names names = parse_file(foundName);
  foundName = find(names);
  // ...
}

This program is expected to open file contents.txt, read names from it; then find a desired name, and do something with it.

But the program will not do it, because I have a bug in this code. Accidentally, I have passed the wrong pointer to function parse_file: a null pointer. I confused them because names were so similar (I didn’t notice that my IDE suggested the wrong name in the hint); the types happened to match…

Now, would you like that this sort of bugs were detected at compile time? The correct answer is “yes”, but is it at all possible? Continue reading

Posted in programming | Tagged , , , , | 21 Comments