A clever comment style

Comments are one of the most useful language features; in practically any programming language. Yet, they can become really a pain. Just consider the following example that I have seen quite often in different variations:

// now, return the difference between the two results
return result1 + result2;

or:

// at this point x must not be negative
return a - b;

You could surely give me even better examples of counterproductive comments. In fact, this thread contains a long list of funny comments in the code.

Because such things really happen, some people come up with guidelines like, “never use comments in your code — make the code self explanatory.” While the direction looks sound, I would not go so far as to making it an ultimate rule.

I guess, we need to accept the shortcomings of comments; instead, let me show you a technique I was taught by my colleague that helps mitigate one comment-related problem. Continue reading

Posted in programming | Tagged | 14 Comments

String’s interface

What I have to say today is fairly obvious, and you probably know about it. But because I have observed the following pattern in my project’s code fairly frequently, I feel it needs to be recorded. Consider this code:

bool fun (const string& code)
{
  assert (code.length() >= 2);

  if (code.substr(0, 2) == string("XX")) {
    // ...
  }

  // ...
}

Can you see what is wrong about it? Please, do not focus on the usage of assert. I only put in order for you to take for granted that the string has two or more characters. Continue reading

Posted in programming | Tagged , , | 12 Comments

Bug of the week

Today we are going to see a case study illustrating a bug. Not a very spectacular one: a typical bug one would encounter in everyday work. We will start with the symptoms, identify the root cause, and suggest measures to prevent similar things from happening in the future. Continue reading

Posted in programming | Tagged , , | 11 Comments

A conditional copy constructor

In this post we will try to define a ‘wrapper’ class template that does or does not have a copy constructor depending on whether the wrapped class has it. This will be a good opportunity to explore in depth a couple of advanced C++ features. Note that this is a rather advanced topic and, unless you are writing or maintaining a generic library, you will probably never need this knowledge.

The problem

By a wrapper class I mean something like boost::optional<T>. It wraps a value of type T: it is an ‘almost type T’ with some special features. Additionally, as in the case of optional, our wrapper does not inherit from T, nor does it contain a data member of type T.

Our goal is that for any type T the following holds:

std::is_copy_constructible<T>::value ==
std::is_copy_constructible<Wrapper<T>>::value;

Continue reading

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

Desired compile-time failures

When new features are proposed to C++ it is desired that they do not introduce breaking changes. This is typically understood as:

  1. Every program that used to compile (was well formed), continues to compile with the same semantics.
  2. A program that failed to compile (was ill-formed), can now be made well formed and assigned new desired semantics.

For instance, the following was an invalid C++03 program:

void feature(std::string s1)
{
  std::string s2 = std::move(s1); // no std::move in C++03
}

Therefore, it is no harm when we make it well formed code in C++11 and assign it some useful semantics. This rule is not followed in 100% of the cases, but this is the idea in general.

However, even though it works in most of the cases, I believe that this criterion of a “safe addition” is not technically correct, as it fails to take into account an important fact: failure to compile certain programs is a useful, important feature, and if these programs suddenly start to compile, it can cause harm. In this post we will go through the cases where compile-time failure is considered a useful feature. Continue reading

Posted in programming | Tagged , | 12 Comments

Defensive programming

Have you ever asked yourself, or participated in a discussion on whether “defensive programming”is a good or a bad thing? The issue is controversial, and recently, while watching talk “Defensive Programming Done Right, Part I” by John Lakos, I realized (I think) why. Term “undefined behavior” means different things to different people. Continue reading

Posted in programming | Tagged | 28 Comments

Using assertions

This post is a response to my recent encounters with fellow programmers who appear to me to be missing the point of assertions and fail to appreciate their usefulness. The first post I have ever written here was on assertions, I still find it good, so there is no need to repeat it; here I will only describe how I observe people treat assertions and why I believe it is wrong. Continue reading

Posted in programming | Tagged , | 10 Comments