1 The Set-up

2 Welcome to 2017

2.1 Programming Languages Change

Like most programming languages (or like most “real” languages, for that matter), C++ has evolved over the years.

• In 1979, Bjarne Stroustroup was working on a dissertation about how to improve the C programmign language.

• In 1983, he produced the first version of what we would now recognize as C++.

  Over the next several years, the decision of what was “C++” and how that might change was driven informally by the language’s inventor, Bjarne Stroustroup, and by the various groups producing C++ compilers.

• In 1998, an international standards committee adopted an international standard (ISO) for C++.

  Most C++ compilers enforce the 1998 standard by default.

• In 2005, the C++ standard committee began releasing drafts of their vision of where C++ should go in the future.

  Compiler writers and programmers experimented with many of the proposed changes, but compilers stuck with the 1998 model by default. The experimental features could generally by activated only with specific compiler options.

  These experimental features were quite unstable. Some turned out to be unworkable and were dropped from the language. Early attempts to compile the new features often led to buggy executables.

• In 2011, the new C++ standard was approved.

• Much smaller revisions to the standard have been published in 2014 and 2017.

2.2 Compiling with the 2017 Standard

Code::Blocks is capable of issuing the proper compiler commands to use the 2017 standard. The warning messages we received have actually indicated what the compiler option is: -std=c++11. But we need to tell Code::Blocks to compile our code with that option.

1. From the Settings menu, select “Compiler…”

2. You should be on the “Global compiler settings” tab. If not, select it.

3. Put a checkmark by the option:

     Have g++ follow ... C++17 ISO ...
   

4. Click OK to accept the changes. Then from the “Project” menu select “Project Clean”, then rebuild your project.

   The code should now compile cleanly.

5. Try running the program.

   You should see some very reasonable values being printed for square roots, followed by a closing message stating how many were printed.

If you are lucky, the closing line printed the correct number. There’s a very good chance, however, that the closing line will print what appears to be a completely random integer. It’s possible that if you run the program repeatedly, you will get a different number printed each time.

2.3 What’s Wrong?

void printTable(int arraySize)
{
  int counter;
  double inputs[] {1.0, 2.0, 100.0, 1000.0};
  cout << "Square Roots\n\n";
  // Print the square roots
  for (double x: inputs)
    {
      cout << "The square root of " << x << " is " << sqrt(x) << endl;
      counter++;
    }
  cout << "\nDone printing " << counter << " square roots." << endl;
}

The problem lies in the fact that here we declare counter, and here and here we make use of the value stored in counter, but nowhere in the code do we ever set counter to its logical starting value of zero.

counter is uninitialized. That means that the first time we come to this statement, counter contains whatever pattern of bits just happened to be residing in its storage location when the function was called, probably something left behind in memory by some other part of the program code or maybe by some completely different program entirely that was running earlier.

• The left-over pattern of bits could, as a block, represent any integer at all – hence the tendency to see almost random behaviors.

• We might get lucky. Maybe the left-over patterns of bits is all zeros – statistically speaking if you took a snapshot of a computer’s memory at any random moment, you would see more blocks of zeros than any other value.

  In that case, our code would actually appear to be working. Programmers hate this kind of bug, because it seems to “hide” until (according to a variation of Murphy’s law) someone else is looking (grading) the code.

  Luckily, the compiler can help us out…

3 Asking the Compiler to Check for Common Mistakes

So we won’t fix the bug yet. Let’s instead see if the compiler can find it for us.

We’re going to add three new options to our compilation:

-Wall -Wextra -O2

• The -W… options add warning messages for a variety of common errors. They are warnings, not errors, and will not actually prevent your code from compiling. They can alert you to potential problems, but only if you actually read and consider the warning messages.

• The -O2 activates optimization, which results in faster-running code. I list it here because the optimizer also does some deeper analysis of our code, which facilitates detecting some of those common errors.

3.1 Catching the Problem

1. From the Settings menu, select “Compiler…”

2. You should be on the Global compiler settings tab. If not, select it. Within that, look for a “Compiler Flags” tab. Again, you are probably already on it. If not, select it.

3. Put a checkmark by each of the following:

      Have g++ follow ... C++11 ISO ...
   
      Enable all common compiler warnings
   
      Enable extra compiler warnings
   

   (The first of these should already be checked from earlier in this exercise.)

4. Click OK to accept the changes. Then from the “Project” menu select “Project Clean”, then rebuild your project.

This time you should get two warnings.

• One points out that the function printTable takes a parameter but that parameter is never used inside the body of the function.

  This is generally a sign that either we don’t need that parameter and can remove it, or that we have misunderstood or forgotten part of what the function is supposed to do and left out some code.

• The other does, indeed, report that counter is uninitialized.

3.2 How to Fix the Problem

There are a couple of “obvious” fixes for our uninitialized variable:

void printTable(int arraySize)
{
  int counter = 0;
  double inputs[] {1.0, 2.0, 100.0, 1000.0};
  cout << "Square Roots\n\n";
  // Print the square roots
  for (double x: inputs)
    {
      cout << "The square root of " << x << " is " << sqrt(x) << endl;
      counter++;
    }
  cout << "\nDone printing " << counter << " square roots." << endl;
}

or

void printTable(int arraySize)
{
  int counter;
  double inputs[] {1.0, 2.0, 100.0, 1000.0};
  cout << "Square Roots\n\n";
  // Print the square roots
  counter = 0;
  for (double x: inputs)
    {
      cout << "The square root of " << x << " is " << sqrt(x) << endl;
      counter++;
    }
  cout << "\nDone printing " << counter << " square roots." << endl;
}

Neither of these is ideal, though the first is better.

What’s wrong with the second one?

void printTable(int arraySize)
{
  int counter;
  double inputs[] {1.0, 2.0, 100.0, 1000.0};
  cout << "Square Roots\n\n";
  // Print the square roots
  counter = 0;
  for (double x: inputs)
    {
      cout << "The square root of " << x << " is " << sqrt(x) << endl;
      counter++;
    }
  cout << "\nDone printing " << counter << " square roots." << endl;
}

It leaves us with a block of code during which counter is legally available for use but not yet initialized.

As programs get modified over time and during testing and debugging, it’s all too easy to slip more and more new code into those kinds of intervals. Eventually, it’s no longer “obvious” that counter hasn’t been initialized yet, and eventually the programmer ecides that it’s OK to insert a statement that tries to make use of the uninitialized variable.

Rule of Thumb: Always initialize your variables in the same statement where you declare them.

So the declaration

int counter = 0;

is definitely preferred.

Why, then, did I say that

void printTable(int arraySize)
{
  int counter = 0;
  double inputs[] {1.0, 2.0, 100.0, 1000.0};
  cout << "Square Roots\n\n";
  // Print the square roots
  for (double x: inputs)
    {
      cout << "The square root of " << x << " is " << sqrt(x) << endl;
      counter++;
    }
  cout << "\nDone printing " << counter << " square roots." << endl;
}

was not an ideal fix?

It runs afoul of another good rule of thumb for good C++ programmers.

Rule of Thumb: Always declare your variables as close as possible to the place where you start using them.

That way you don’t have to remember what the initial value was or whether you have already used that variable name for a completely different purpose (a particularly common mistake with variables named “i”, “j”, etc.). If you have added comments to your variable declaration to explain what that variable is used for, this brings those comments closer to they place where they are relevant as well.

So the ideal fix for the uninitialized variable is:

void printTable(int arraySize)
{
  double inputs[] {1.0, 2.0, 100.0, 1000.0};
  cout << "Square Roots\n\n";
  // Print the square roots
  int counter = 0;
  for (double x: inputs)
    {
      cout << "The square root of " << x << " is " << sqrt(x) << endl;
      counter++;
    }
  cout << "\nDone printing " << counter << " square roots." << endl;
}

which satisfies both of those rules of thumb.

3.3 Fix it!

1. Edit the code to make the above change.

2. Compile and execute the program.