Your own error code

I was recently implementing the “classification of error conditions” in my application offered by the functionality behind std::error_code. In this post I want to share some of my experience and insight.

C++11 comes with a quite sophisticated mechanism for classifying error conditions. You may have encountered names like “error code”, “error condition”, error category”, but figuring out what good they are, and how to use them is difficult. The only valuable source of information on the subject in the Internet is a series of blog posts by Christopher Kohlhoff, the author of Boost.Asio library:

And this was a really good start for me. But still, I believe it would be beneficial to have more than one source of information, and more than one way of explaining the subject. So here we go… Continue reading

Posted in programming | Tagged , | Leave a comment

Compile-time string concatenation

We will start with a bug, taken from real life. It spans across three files:

#include <string>

struct Service
{
  static const std::string NAME;
};
#include "service.h"

const std::string Service::NAME = "SERVICE1";
#include "service.h"
#include <iostream>

const std::string MSG = "service " + Service::NAME + " ready";

int main()
{
  std::cout << MSG << std::endl;
}

Question: what happens when this program is executed? Continue reading

Posted in programming | Tagged , , , , , | 9 Comments

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