Inserting characters into an existing string can be done via the insert() function.

string sString("aaaa");
cout << sString << endl;

sString.insert(2, string("bbbb"));
cout << sString << endl;

sString.insert(4, "cccc");
cout << sString << endl;

aaaa
aabbbbaa
aabbccccbbaa

Here’s a crazy version of insert() that allows you to insert a substring into a string at an arbitrary index:

string sString("aaaa");

const string sInsert("01234567");
sString.insert(2, sInsert, 3, 4); // insert substring of sInsert from index [3,7) into sString at index 2
cout << sString << endl;

aa3456aa

There is a flavor of insert() that inserts the first portion of a C-style string:

string sString("aaaa");

sString.insert(2, "bcdef", 3);
cout << sString << endl;

aabcdaa

There’s also a flavor of insert() that inserts the same character multiple times:

string sString("aaaa");

sString.insert(2, 4, 'c');
cout << sString << endl;

aaccccaa

And finally, the insert() function also has three different versions that use iterators:

Index

17.6 — std::string appending

Appending strings to the end of an existing string is easy using either operator+=, append(), or push_back() function.

string sString("one");

sString += string(" two");

string sThree(" three");
sString.append(sThree);

cout << sString << endl;

one two three

There’s also a flavor of append() that can append a substring:

string sString("one ");

const string sTemp("twothreefour");
sString.append(sTemp, 3, 5); // append substring of sTemp starting at index 3 of length 5
cout << sString << endl;

one three

Operator+= and append() also have versions that work on C-style strings:

string sString("one");

sString += " two";
sString.append(" three");
cout << sString << endl;

one two three

There is an additional flavor of append() that works on C-style strings:

string sString("one");

sString.append("threefour", 5);
cout << sString << endl;

one three

There is also a set of functions that append characters. Note that the name of the non-operator function to append a character is push_back(), not append()!

string sString("one");

sString += ' ';
sString.append('2');
cout << sString << endl;

one 2

It turns out there is an append() function for characters, that looks like this:

string sString("aaa");

sString.append(4, 'b');
cout << sString << endl;

aaabbbb

There’s one final flavor of append() that you won’t understand unless you know what iterators are. If you’re not familiar with iterators, you can ignore this function.

17.7 — std::string inserting

Index

17.5 — std::string assignment and swapping

The easiest way to assign a value to a string is to the use the overloaded operator= function. There is also an assign() member function that duplicates some of this functionality.

string sString;

// Assign a string value
sString = string("One");
cout << sString << endl;

const string sTwo("Two");
sString.assign(sTwo);
cout << sString << endl;

// Assign a C-style string
sString = "Three";
cout << sString << endl;

sString.assign("Four");
cout << sString << endl;

// Assign a char
sString = '5';
cout << sString << endl;

// Chain assignment
string sOther;
sString = sOther = "Six";
cout << sString << " " << sOther << endl;

One
Two
Three
Four
5
Six Six

The assign() member function also comes in a few other flavors:

const string sSource("abcdefg");
string sDest;

sDest.assign(sSource, 2, 4); // assign a substring of source from index 2 of length 4
cout << sDest << endl;

cdef

string sDest;

sDest.assign("abcdefg", 4);
cout << sDest << endl;

abcd

string sDest;

sDest.assign(4, 'g');
cout << sDest << endl;

gggg

Swapping

If you have two strings and want to swap their values, there are two functions both named swap() that you can use.

string sStr1("red");
string sStr2("blue);

cout << sStr1 << " " << sStr2 << endl;
swap(sStr1, sStr2);
cout << sStr1 << " " << sStr2 << endl;
sStr1.swap(sStr2);
cout << sStr1 << " " << sStr2 << endl;

red blue
blue red
red blue

17.6 — std::string appending

Index

17.4 — std::string character access and conversion to c-style strings

Note: All of the I/O functionality in this lesson lives in the std namespace. That means all I/O objects and functions either have to be prefixed with “std::”, or the “using namespace std;” statement has to be used.

The extraction operator

As seen in many lessons now, we can use the extraction operator (>>) to read information from an input stream. C++ has predefined extraction operations for all of the built-in data types, and you’ve already seen how you can overload the extraction operator for your own classes.

When reading strings, one common problem with the extraction operator is how to keep the input from overflowing your buffer. Given the following example:

char buf[10];
cin >> buf;

what happens if the user enters 18 characters? The buffer overflows, and bad stuff happens. Generally speaking, it’s a bad idea to make any assumption about how many characters your user will enter.

One way to handle this problem is through use of manipulators. A manipulator is an object that is used to modify a stream when applied with the extraction (>>) or insertion (<<) operators. One manipulator you have already worked with extensively is "endl", which both prints a newline character and flushes any buffered output.

C++ provides a manipulator known as setw (in the iomanip.h header) that can be used to limit the number of characters read in from a stream. To use setw(), simply provide the maximum number of characters to read as a parameter, and insert it into your input statement like such:

#include <iomanip.h>
char buf[10];
cin >> setw(10) >> buf;

This program will now only read the first 9 characters out of the stream (leaving room for a terminator). Any remaining characters will be left in the stream until the next extraction.

Extraction and whitespace

The one thing that we have omitted to mention so far is that the extraction operator works with “formatted” data — that is, it skips whitespace (blanks, tabs, and newlines).

Take a look at the following program:

int main()
{
    char ch;
    while (cin >> ch)
        cout << ch;

    return 0;
}

When the user inputs the following:

Hello my name is Alex

The insertion operator skips the spaces and the newline. Consequently, the output is:

HellomynameisAlex

Oftentimes, you’ll want to get user input but not discard whitespace. To do this, the istream class provides many functions that can be used for this purpose.

One of the most useful is the get() function, which simply gets a character from the input stream. Here’s the same program as above using get():

int main()
{
    char ch;
    while (cin.get(ch))
        cout << ch;

    return 0;
}

Now when we use the input:

Hello my name is Alex

The output is:

Hello my name is Alex

get() also has a string version that takes a maximum number of characters to read:

int main()
{
    char strBuf[11];
    cin.get(strBuf, 11);
    cout << strBuf << endl;

    return 0;
}

If we input:

Hello my name is Alex

The output is:

Hello my n

Note that we only read the first 10 characters (we had to leave one character for a terminator). The remaining characters were left in the input stream.

One important thing to note about get() is that it does not read in a newline character! This can cause some unexpected results:

int main()
{
    char strBuf[11];
    // Read up to 10 characters
    cin.get(strBuf, 11);
    cout << strBuf << endl;

    // Read up to 10 more characters
    cin.get(strBuf, 11);
    cout << strBuf << endl;
    return 0;
}

If the user enters:

Hello!

The program will print:

Hello!

and then terminate! Why didn’t it ask for 10 more characters? The answer is because the first get() read up to the newline and then stopped. The second get() saw there was still input in the cin stream and tried to read it. But the first character was the newline, so it stopped immediately.

Consequently, there is another function called getline() that works exactly like get() but reads the newline as well.

int main()
{
    char strBuf[11];
    // Read up to 10 characters
    cin.getline(strBuf, 11);
    cout << strBuf << endl;

    // Read up to 10 more characters
    cin.getline(strBuf, 11);
    cout << strBuf << endl;
    return 0;
}

This code will perform as you expect, even if the user enters a string with a newline in it.

If you need to know how many character were extracted by the last call of getline(), use gcount():

int main()
{
    char strBuf[100];
    cin.getline(strBuf, 100);
    cout << strBuf << endl;
    cout << cin.gcount() << " characters were read" << endl;

    return 0;
}

A special version of getline() for std::string

There is a special version of getline() that lives outside the istream class that is used for reading in variables of type std::string. This special version is not a member of either ostream nor istream, and is included in the string header. Here is an example of it’s use:

#include <string>
#include <iostream>

int main()
{
    using namespace std;
    string strBuf;
    getline(cin, strBuf);
    cout << strBuf << endl;

    return 0;
}

A few more useful istream functions

There are a few more useful input functions that you might want to make use of:

ignore() discards the first character in the stream.
ignore(int nCount) discards the first nCount characters.
peek() allows you to read a character from the stream without removing it from the stream.
unget() returns the last character read back into the stream so it can be read again by the next call.
putback(char ch) allows you to put a character of your choice back into the stream to be read by the next call.

istream contains many other functions and variants of the above mentioned functions that may be useful, depending on what you need to do. However, those topics are really more suited for a tutorial or book focusing on the standard library (such as the excellent “The C++ Standard Template Library” by Nicolai M. Josuttis).

13.3 — Output with ostream and ios

Index

13.1 — Input and output (I/O) streams

The dangerous errors are the ones that compilers are unable to detect. These errors are much less likely to be noticed, and can cause severe consequences such as incorrect outputs, corrupted data, and/or program crashes. As the size of a programming project increases, the complexity of the logic and large number of paths of execution can help obscure these bugs, causing them to appear only intermittently, making them particularly hard to track down and debug. Although this list may be mostly review to experienced programmers, the consequences of making one of these errors is also amplified due to the scale and commercial nature of the projects experienced programmers tend to work on.

These examples were all tested using Visual Studio 2005 Express using the default warning level. Your results may vary on other compilers. I highly recommend all programmers use the highest warning level possible!. Some items that may not be flagged as a potential problem at the default warning level may be caught at the highest warning level!

(Note: This article is part 1 in an intended series of articles)

1) Uninitialized variables

Uninitialized variables are one of the most devious mistakes commonly made in C++. Memory allocated to a variable in C++ is not cleared or zeroed upon allocation. Consequently, an uninitialized variable will have some value, but there is no way to predict what that value will actually be. Furthermore, the value of the variable may change each time the program is executed. This can result in intermittent problems, which are particularly hard to track down. Consider the following snippet:

if (bValue)
    // do A
else
    // do B

If bValue is uninitialized, it could evaluate to either true or false, and either branch could be taken.

In some basic cases, the compiler will be able to inform you of an uninitialized variable. The following causes a compiler warning on most compilers:

int foo()
{
int nX;
return nX;
}

However, other simple cases generally do not produce warnings:

void increment(int &nValue)
{
    ++nValue;
}

int foo()
{
int nX;
increment(nX);
return nX;
}

The above may not produce a warning because the compiler typically doesn’t keep track of whether increment() assigns a value to nValue.

Uninitialized variables are even more likely to appear in classes, where member declaration are generally separated by from the constructor implementation:

class Foo
{
private:
    int m_nValue;

public:
    Foo();
    int GetValue() { return m_bValue; }
};

Foo::Foo()
{
    // Oops, we forget to initialize m_nValue
}

int main()
{
    Foo cFoo;
    if (cFoo.GetValue() > 0)
        // do something
    else
        // do something else
}

Note that m_nValue is never initialized. Consequently, GetValue() returns a junk value, and either branch may be executed.

New programmers often make the following mistake when declaring multiple variables:

int nValue1, nValue2 = 5;

The assumption being made here is that 5 is assigned to both nValue1 and nValue2, when in fact the value of 5 is only assigned to nValue2, and nValue1 is uninitialized.

Because uninitialized variables can evaluate to any value, which can cause the program to exhibit different behavior each time it is run, problems caused by uninitialized variables are particularly hard to find. One run, the program may work fine. The next time, it may crash. The after that, it may produce the wrong output.

To compound problems finding uninitialized variables, variable declared when running the program in a debugger are typically zeroed. This means your program may work fine every time when run in a debugger, but crash intermittently in release mode! If this is the case, an uninitialized variable is often the root of your problem.

2) Integer division

Most binary operators in C++ require both operands to be the same type. If the operands are of different types, one of the operands is promoted to match the type of the other.

In C++, the division operator can be thought of as two different operators: one that works on integer operands, and one that works on floating point operands. If the operands are of a floating point type, the division operator will return a floating point value:

float fX = 7;
float fY = 2;
float fValue = fX / fY; // fValue = 3.5

If the operands are of an integer type, the division operator will drop any faction and return an integer value:

int nX = 7;
int nY = 2;
int nValue = nX / nY; // nValue = 3

If one operand is an integer, and the other is a floating point value, the integer value will be promoted to a floating point type:

float fX = 7.0;
int nY = 2;
float fValue = fX / nY;

// nY is promoted to float, floating point division used
// fValue = 3.5

Many new programmers attempt to do the following:

int nX = 7;
int nY = 2;
float fValue = nX / nY;  // fValue = 3 (not 3.5!)

The underlying assumption here is that nX / nY will result in a floating point division because the result is being assigned to a floating point value. However, this is not the case. nX / nY is evaluated first, resulting in an integer value, which is then promoted to a float and assigned to fValue. However, by that point, the fraction has already been lost.

In order to force two integers to use floating point division, one of the values should be cast to a floating point value:

int nX = 7;
int nY = 2;
float fValue = static_cast<float>(nX) / nY; // fValue = 3.5

Because nX is being explicitly cast to a float, nY will be implicitly promoted to a float, which will cause the division operator to perform floating point division, resulting in a value of 3.5.

It is often hard to tell at a glance whether a given division operation is performing integer or floating point division:

z = x / y; // is this integer or floating point division?

However, using Hungarian Notation can help disambiguate the case and help prevent mistakes:

int nZ = nX / nY; // integer division
double dZ = dX / dY; // floating point division

One other interesting issue with integer division is that C++ does not define how to truncate the result when one operand is negative. Consequently, the compiler is free to truncate up or down! For example, -5 / 2 can evaluate to either -3 or -2, depending on whether the compiler rounds down or rounds toward 0. Most modern compilers round towards 0.

3) = vs ==

This one is an oldie but a goodie. Many beginning C++ programmers confuse the meaning of the assignment operator (=) with the equality operator (==). But even programmers who know the difference can make a typo that will have unintended results:

// if nValue is 0, return 1, otherwise return nValue
int foo(int nValue)
{
    if (nValue = 0) // TYPO!
        return 1;
    else
        return nValue;
}

int main()
{
    std::cout << foo(0) << std::endl;
    std::cout << foo(1) << std::endl;
    std::cout << foo(2) << std::endl;

    return 0;
}

Function foo() is intended to return 1 if nValue is 0, otherwise return nValue. But due to inadvertently using the assignment operator instead of the equality operator, the program produces an unexpected result:

0
0
0

When the if statement in foo() is evaluated, nValue is assigned the value of 0. if (nValue = 0) evaluates the same way that nValue = 0; if (nValue) evaluates. Consequently, the if condition is false, which causes the else statement to return nValue, which was just assigned the value of 0!

Consequently, this function always returns 0.

Running a modern compiler at the highest warning level will cause it to issue a warning when an assignment is used in a conditional statement, or a note that the statement does nothing when an equality test is used instead of an assignment outside of a conditional. This is one issue that is essentially fixable — if you use the higher warning levels.

4) Mixing signed and unsigned values

As mentioned in the section on integer division, most binary operators in C++ require both operands to be the same type. If the operands are of different types, one of the operands is promoted to match the type of the other.

This can lead to some very unexpected results when mixing signed and unsigned values! Consider the following case:

cout << 10 - 15u; // 15u is unsigned

One would expect the answer to be -5. However, because 10 is an signed integer and 15 is an unsigned integer, the type promotion rules come into effect here. The hierarchy used for type promotion in C++ looks like this:

long double (highest)
double
float
unsigned long int
long int
unsigned int
int (lowest)

Because the int operand is considered lower than the unsigned int operand, the int is promoted to an unsigned int. Fortunately, 10 is already a positive number, so the promotion does not cause our number to be interpreted any differently.

Thus, we effectively have:

cout << 10u - 15u

Here’s where the tricky part happens. Because both variables are unsigned integers, the result of the operation is also an unsigned integer! 10u – 15u = -5u. But unsigned variables can not hold negative numbers, and thus the -5 is interpreted as 4,294,967,291 (assuming 32 bit integers).

Consequently, the following program:

cout << 10 - 15u; // 15u is unsigned

prints 4,294,967,291, not -5.

This situation can come up in more obscure forms:

int nX;
unsigned int nY;

if (nX - nY < 0)
    // do something

Due to the type conversion, this if statement will always evaluate to false, which is clearly not what the programmer intends!

5) delete vs. delete[]

Many C++ programmers forget that there are actually two forms of the both the new and delete operators: a scalar version, and an array version.

Operator new is used to allocate scalar (non-array) data on the heap. If the object being allocated is a class type, the object’s constructor is called.

Foo *pScalar = new Foo;

The delete operator is used to destroy a scalar object that has been allocated using the new operator. If the object being destroyed is a class type, the object’s destructor is called.

delete pScalar;

Now consider the following snippet:

Foo *pArray = new Foo[10];

This snippet allocates an array of 10 Foo. Because the subscript [10] is placed after the int type specifier, many C++ programmers do not realize that operator new[] is being called to do the array allocation instead of operator new. Operator new[] ensures that the constructor is called for each object being constructed.

Conversely, to delete an array, the delete[] operator should be used:

delete[] pArray;

This ensures that the destructor for each object in the array is called.

If the delete operator is used on an array, only the first object will be destructed, and heap corruption can result!

6) Side effects in compound expressions or function calls

A side effect is a result of an operator, expression, statement, or function that persists even after the operator, expression, statement, or function has finished being evaluated.

Side effects can often be useful:

x = 5;

The assignment operator has the side effect of changing the value of x permanently. Other C++ operators with useful side effects include *=, /=, %=, +=, -=, <<=, >>=, &=, |=, ^=, and the infamous ++ and — operators.

However, there are several places in C++ where the order of operations is undefined, and these can lead to inconsistent behavior. For example:

void multiply(int x, int y)
{
    using namespace std;
    cout << x * y << endl;
}

int main()
{
    int x = 5;
    std::cout << multiply(x, ++x);
}

Because the order of evaluation of the function parameters for multiply() is undefined, this could print 30 or 36, depending on whether x or ++x is evaluated first.

A slightly stranger example involving operators:

int foo(int x)
{
return x;
}

int main()
{
    int x = 5;
    std::cout << foo(x) * foo(++x);
}

Because the order of evaluation of the operands of C++ operators is undefined (for most operators — there are a few exceptions), this could also print 30 or 36, depending on whether the left or right operand is evaluated first.

Also consider the following compound expression:

if (x == 1 && ++y == 2)
    // do something

The intent of the programmer is probably to say “if x is 1 and the pre-incremented value of y is 2, then do something”. However, if x does not equal 1, C++ uses short-circuit evaluation, which means that ++y never gets evaluated! Thus, y will only be incremented if x evaluates to 1, which is probably not what the programmer intended!

A good rule of thumb is to put any operator that causes a side effect in it’s own statement.

7) Switch statements without break

Another classic mistake that new programmers make is forgetting to use break to end a switch block:

switch (nValue)
{
    case 1: eColor = Color::BLUE;
    case 2: eColor = Color::PURPLE;
    case 3: eColor = Color::GREEN;
    default: eColor = Color::RED;
}

When the switch expression evaluates to the same value as the case label expression, execution starts at the matching case statement. Execution then continues until either the end of the switch block is reached, or a return, goto, or break statement is executed. Any other labels are ignored!

Consider what happens if nValue is 1 in the above program. Case 1 matches, so eColor is set to Color::BLUE. Evaluation proceeds to the next statement, which sets eColor to Color::PURPLE. The next statement sets it to Color::GREEN. And finally, it gets set to Color::RED.

In fact, this snippet ends up setting eColor to COLOR::RED no matter what the value of nValue is!

The correct way to write the above program is:

switch (nValue)
{
    case 1: eColor = Color::BLUE;  break;
    case 2: eColor = Color::PURPLE;  break;
    case 3: eColor = Color::GREEN;  break;
    default: eColor = Color::RED;  break;
}

The break terminates the case statement, thus causing eColor to retain the value that the programmer intended.

Although this is very basic switch/case logic, it is very easy to miss a break statement and end up with inadvertent fall-through.

8) Calling virtual functions in constructors

Consider the following program:

class Base
{
private:
    int m_nID;
public:
    Base()
    {
        m_nID = ClassID();
    }

    // ClassID returns a class-specific ID number
    virtual int ClassID() { return 1; }

    int GetID() { return m_nID; }
};

class Derived: public Base
{
public:
    Derived()
    {
    }

    virtual int ClassID() { return 2; }
};

int main()
{
    Derived cDerived;
    cout << cDerived.GetID(); // prints 1, not 2!
    return 0;
}

In this program, the programmer has called a virtual function inside the constructor of a base class, expecting it to resolve to Derived::ClassID(). It doesn’t — and consequently, the program prints 1 instead of 2.

When an class that has been derived from a base classes is instantiated, the base class object is constructed before the derived class object. This is done because the derived class members may be dependent upon members of the base class already being initialized. Consequently, when the base object constructor is being executed, there is no derived object! It hasn’t been created yet. Thus, any call to a virtual function can only resolve to the level of the base class, not the derived class.

As pertains to this example, when the Base portion of cDerived is being constructed, the Derived portion does not exist yet. Thus, the function call to ClassID() resolves to Base::ClassID() (not Derived::ClassID()), which sets m_nID to 1.

Once the Derived portion of cDerived has been constructed, any calls to ClassID() on this object will resolve to Derived::ClassID() as anticipated.

Note that some other programming languages (such as C# and Java) will resolve virtual function calls to the most derived class even if the derived class has not been initialized yet! C++ differs in this regard, and does so for the programmer’s safety. That is not to say one way is necessarily better than the other, but merely to denote that different languages may have different behaviors.

Conclusion

As this is the first article in this series, I thought it appropriate to start with some of the more basic issues that new programmers will encounter. Future articles in this series will tackle programming mistakes of an increasingly complex nature.

Regardless of a programmer’s experience level, mistakes happens, whether through lack of knowledge, a typo, or general carelessness. Being aware of which issues are most likely to cause trouble can help reduce the probability that they will cause trouble. While there is no substitute for experience and knowledge, good unit testing can help catch many of these before they get buried under layers of other code!

Related articles:

• Six language-independent ways to write better code

The for statement looks pretty simple:

for (init-statement; expr1; expr2)
   statement;

The easiest way to think about for loops is convert them into equivalent while loops. In older versions of C++, the above for loop was exactly equivalent to:

// older compilers
init-statement;
while (expr1)
{
    statement;
    expr2;
}

However, in newer compilers, variables declared during the init-statement are now considered to be scoped inside the while block rather than outside of it. This is known as loop scope. Variables with loop scope exist only within the loop, and are not accessible outside of it. Thus, in newer compilers, the above for loop is effectively equivalent to the following while statement:

// newer compilers
{
    init-statement;
    while (expr1)
    {
        statement;
        expr2;
    }
} // variables declared in init-statement go out of scope here

A for statement is evaluated in 3 parts:

1) Init-statement is evaluated. Typically, the init-statement consists of variable declarations and assignments. This statement is only evaluated once, when the loop is first executed.

2) The expression expr1 is evaluated. If expr1 is false, the loop terminates immediately. If expr1 is true, the statement is executed.

3) After the statement is executed, the expression expr2 is evaluated. Typically, this expression consists of incremented/decrementing the variables declared in init-statement. After expr2 has been evaluated, the loop returns to step 2.

Let’s take a look at an example of a for loop:

for (int iii=0; iii < 10; iii++)
    cout << iii << " ";

What does this do? Although this looks somewhat confusing, let’s take it piece by piece.

First, we declare a loop variable named iii, and assign it the value 0.

Second, the iii < 10 is evaluated, and since iii is 0, 0 < 10 evaluates to true. Consequently, the statement executes, which prints 0.

Third, After the statement executes, iii++ is evaluated, which increments iii to 1. Then the loop goes back to the second step.

1 < 10 is evaluates to true, so the loop iterates again. The statement prints 1, and iii is incremented to 2. 2 < 10 evaluates to true, the statement prints 2, and iii is incremented to 3. And so on.

Eventually iii is incremented to 10, 10 < 10 evaluates to false, and the loop exits.

Consequently, this program prints the result:

0 1 2 3 4 5 6 7 8 9

For loops can be hard for new programmers to read -- however, experienced programmers love them because they are a very compact way to do loops of this nature. Let's uncompact the above for loop by converting it into it's while-statement equivalent:

{
    int iii = 0;
    while (iii < 10)
    {
        cout << iii << " ";
        iii++;
    }
}

That doesn't look so bad, does it? Note that the outer braces are necessary here, because iii goes out of scope when the loop ends (in newer compilers).

Here is an example of a for loop affecting a variable declared outside the for loop:

// returns the value nBase ^ nExp
int Exponent(int nBase, int nExp)
{
    int nValue = 1;
    for (int iii=0; iii < nExp; iii++)
        nValue *= nBase;

    return nValue;
}

This function returns the value nBase^nExp (nBase to the nExp power).

This is a straightforward incrementing for loop, with iii looping from 0 up to (but excluding) nExp.

If nExp is 0, the for loop will execute 0 times, and the function will return 1.
If nExp is 1, the for loop will execute 1 time, and the function will return 1 * nBase.
If nExp is 2, the for loop will execute 2 times, and the function will return 1 * nBase * nBase.

Although most for loops increment the loop variable by 1, we can decrement it as well:

for (int iii = 9; iii >= 0; iii--)
    cout << iii << " ";

This prints the result:

9 8 7 6 5 4 3 2 1 0

Alternately, we can change the value of our loop variable by more than 1 with each iteration:

for (int iii = 9; iii >= 0; iii -= 2)
    cout << iii << " ";

This prints the result:

9 7 5 3 1

Off-by-one errors

One of the biggest problems that new programmers have with for loops is off-by-one errors. Off-by-one errors occur when the loop iterates one too many or one too few times. This generally happens because the wrong relational operator is used in expr1 (eg. > instead of >=). These errors can be hard to track down because the compiler will not complain about them -- the program will run fine, but it will produce the wrong result.

When writing for loops, remember that the loop will execute as long as expr1 is true. Generally it is a good idea to test your loops using known values to make sure that they work as expected. If your loop produces the right result when it iterates 0, 1, and 2 times, it will probably work for all number of iterations.

Omitted expressions

It is possible to write for loops that omit any or all of the expressions. For example:

int iii=0;
for ( ; iii < 10; )
{
    cout << iii << " ";
    iii++;
}

This for loop produces the result:

0 1 2 3 4 5 6 7 8 9

Rather than having the for loop do the initialization and incrementing, we've done it manually. We have done so purely for academic purposes in this example, but there are cases where not declaring a loop variable (because you already have one) or incrementing it (because you're incrementing it some other way) are desired.

Although you do not see it very often, it is worth noting that the following example produces an infinite loop:

for (;;)
    statement;

The above example is equivalent to:

while (true)
    statement;

Null statements

It is also possible to omit the statement part of a for loop. This is called a null statement, and it is declared by using a single semicolon.

for (int iii=0; iii < 10; iii++)
    ;

This loop increments iii using the ++ operator 10 times. When the statement is executed, the null statement evaluates to nothing, and consequently, doesn't do anything. For readability purposes, the semicolon of a null statement is typically placed on it's own line. This indicates that the use of a null statment was intentional, and makes it harder to overlook the use of the null statement.

Null statements can actually be used anywhere a regular statement can (though they typically aren't, since they serve no purpose other than as a do-nothing placeholder). Because of this, it is easy to make the following mistake:

if (nValue == 0);
    nValue = 1;

The programmer's intent was to assign nValue the value of 1 only if nValue had the value 0. However, due to the misplaced semicolon after the if statement, this actually executes as:

if (nValue == 0)
    ;
nValue = 1;

Consequently, nValue is set to 1 regardless of it's previous value!

Multiple declarations

Although for loops typically iterate over only one variable, sometimes for loops need to work with multiple variables. When this happens, the programmer can make use of the comma operator in order to initialize or change the value of multiple variables:

    for (int iii=0, jjj=9; iii < 10; iii++, jjj--)
        cout << iii << " " << jjj << endl;

This loop initializes two variable: iii to 0, and jjj to 9. It iterates iii over the range 0 to 9, and each iteration iii is incremented and jjj is decremented.

This program produces the result:

0 9
1 8
2 7
3 6
4 5
5 4
6 3
7 2
8 1
9 0

This is the only place in C++ where the comma operator typically gets used.

Conclusion

For loops are the most commonly used loop in the C++ language. Even though it's syntax is typically a bit confusing to new programmers, you will see for loops so often that you will understand them in no time at all!

Quiz

1) Write a for loop that prints every other number from 0 to 20.

2) Write a function named SumTo() that takes an integer parameter named nValue, and returns the sum of all the numbers from 1 to nValue.

For example, SumTo(5) should return 15, which is 1 + 2 + 3 + 4 + 5.

Hint: Use a non-loop variable to accumulate the sum as you iterate from 1 to nValue, much like the Exponent() example above uses nValue to accumulate the return value each iteration.

3) What's wrong with the following for loop?

// Print all numbers from 9 to 0
for (unsigned int nCount = 9; nCount >= 0; nCount--)
    cout << nCount << " ";

Quiz solutions

1) Show Solution

for (int iii=0; iii <= 20; iii += 2)
    cout << iii << endl;

2) Show Solution

int SumTo(int nSumTo)
{
    int nSum = 0;
    for (int iii=1; iii <= nSumTo; iii++)
        nSum += iii;

    return nSum;
}

3) Show Solution

5.8 -- Break and continue

Index

5.6 -- Do while statements

http://www.ibm.com/developerworks/linux/library/l-clear-code/index.html?ca=drs-

Here are the recommendations of the author, along with my own comments:
1) Comment like a smart person.

I can’t emphasize this enough. Code that seems beyond obvious has a funny way of reading like a foreign language after a couple of months. Comment everything — and don’t just state the obvious. Try to write the comment as if you were writing it for someone else who has no prior knowledge of what you are doing. Because in three or six months, that person will be you.

2) Use #define a lot. No, a LOT.

Right sentiment, wrong implementation. As the article says, it’s a very bad idea to hard-code numbers into your program. Inevitably, you’ll want to change something in the future, and it’s really difficult if everything there are numbers scattered everywhere. Using #define helps document what you are doing, and makes it easy to change those numbers in the future.

But #define is so… C. There are a few problems with using #defines. First, because #define is a preprocessor command, the preprocessor goes through and replaces all your defined names with their corresponding values. This means those names are not available when you are debugging, which makes debugging more difficult. Assume you have a function call that passes in a #defined value called EXP_PER_KILL. Even though the code you are debugging may says AddExp(EXP_PER_KILL), you won’t have any idea what EXP_PER_KILL evaluates to unless you can locate it’s definition.

Second, #defined variables are always declared in the global scope regardless of where they are defined.

In the world of C++, we can do better. One better choice is to use a const variable. Const variables are actual objects, so you can easily get their values in the debugger, and they follow normal scoping rules. The other better choice is to use an enum, which has the same benefits.

3) Don’t use variable names that will mock you.

Not much to say about this — naming your variables things that makes their purpose clear is an important aspect of documenting your code.

4) Do error checking. You make errors. Yes, you.

This one is both easier and harder than it looks. Inevitably you will misuse a function you wrote by passing it an invalid parameter, or something will go wrong and a pointer will end up NULL when you were expecting it to have a value or vice-versa. Checking for these things is good and can and will keep your program from crashing. However, if you do detect an error and then do not do anything intelligent with that information, your program might as well just crash and get it over with.

Just as big a problem as detecting an error is doing something intelligent about it. If you’re writing a reusable function, the intelligent thing generally involves informing your caller that something went wrong and leaving it up to the caller to handle the problem. If you’re the caller, or you’re writing a function that’s integral to your program, figuring out how to handle errors can be a tricky proposition. Do you pop up a message box warning? Do you ask the user for new input? Do you save the user’s data and then terminate the program? It really depends, and there’s no easy solution.

But before you can do any of these things, you have to detect than an error occurred, and that’s why I agree with the author that this is important.

5) “Premature optimization is the root of all evil.” – Donald Knuth

One of the biggest problems new or overzealous programmers run into is trying to write code that is as fast as possible at the expense of things like code readability. This is almost always a bad idea. It IS a good idea to pick an algorithm that’s right for the problem you’re trying to solve — for example, if you’re doing lots of element insertions and deletions, a linked list is probably going to be a better choice than an array. But that doesn’t mean you have to design an algorithm that squeezes out every last bit of performance out of the linked list. Efficiency generally comes at the expense of legibility, and honestly, with a few exceptions, legibility is more important, because at some point, you’re going to have to fix a bug, or expand your code, and code that’s tricked-out to be as efficient as possible isn’t going to be conducive to either of those things.

Once your code is written, you can always profile it to find out where the ACTUAL bottlenecks are, rather than prematurely act on where you perceive the bottlenecks may be. With properly implemented code that utilizes concepts such as encapsulation, swapping out one algorithm for a better one when needed is often no problem.

6) Don’t be too clever by half.

This is sort of along the same lines as #5. It’s almost always a better idea to write code that is clean, straightforward, and legible than code that is as efficient as possible. As I wrote in the section on comments, if you need a comment to explain what your line of code is doing, it probably needs to be rewritten, not commented.

Many of you have heard of the KISS acronym — Keep It Simple, Stupid. It applies to code too.