When working with derived classes, it’s fairly easy to inadvertently create a new virtual function in the derived class when you actually meant to override a function in the base class. This happens when you fail to properly match the function prototype in the derived class with the one in the base class. . . . → Read More: B.6 — New virtual function controls: override, final, default, and delete]]> override

When working with derived classes, it’s fairly easy to inadvertently create a new virtual function in the derived class when you actually meant to override a function in the base class. This happens when you fail to properly match the function prototype in the derived class with the one in the base class. For example:

class Base
{
    virtual void A(float=0.0);
    virtual void B() const;
};

class Derived: public Base
{
    virtual void A(int=0); // specifies parameter as int instead of float, treated as new function
    virtual void B(); // specifies function as non-const, treated as new function
};

When this happens, it’s can be easy to make a function call to A() or B() and expect to get the derived version but end up getting the base version instead.

This phenomena can also easily occur when you add a new parameter to a function in Base but forget to update the version in Derived. When that happens, the function that was an override in Derived is no longer an override, and your code mysteriously stops working. These kinds of problems can be hard to find because the change that triggers them is so innocuous looking.

C++11 introduces a new identifier called override that allows you to explicitly mark functions you intend to be overrides. If the function is not an override, the compiler will complain about it. For example:

class Base
{
    virtual void A(float=0.0);
    virtual void B() const;
    virtual void C();
    void D();
};

class Derived: public Base
{
    virtual void A(int=0) override; // compile error because Derived::A(int) does not override Base::A(float)
    virtual void B() override; // compile error because Derived::B() does not override Base::B() const
    virtual void C() override; // ok!  Derived::C() overrides Base::C()
    void D() override; // compile error because Derived::D() does not override Base::D()
};

Although use of the override identifier is not required, it is highly recommended, as it will help prevent inadvertent errors.

(If you’re wondering why this was implemented as an identifier rather than a keyword, I presume this was done so that the name “override” can be used as a normal variable name in other contexts. If it had been defined as a keyword, it would be reserved in all contexts, which might break existing applications)

final

There are occasionally times when you don’t want to allow someone to override a virtual function, or even create a derived class. C++11 adds the identifier final to provide this functionality.

The following example shows the use of the final identifier to make a function non-overrideable:

class Base
{
    virtual void A() final; // final identifier marks this function as non-overrideable
};

class Derived: public Base
{
    virtual void A(); // trying to override final function Base::A() will cause a compiler error
};

The final identifier can also be used on classes to make them non-inheritable:

class Base final // final identifier marks this class as non-inheritable
{
};

class Derived: public Base // trying to override final class Base will cause a compiler error
{
};

There are some legitimate reasons to make functions or classes final. For example, the most common use of final is to ensure that an immutable class stays immutable. An immutable class is a specially-designed class whose state cannot be modified after it is created. Without the final identifier, a derived class could add functions that could cause the class to become mutable. If the base class is made final, it cannot be subclasses, and this is avoided.

However, generally speaking, unless you have a really good reason, use of final should generally be avoided. And if you do use the final keyword, document why, as it will likely not be obvious to whomever inherits your code.

default

By default, C++ will provide a default constructor, copy constructor, copy assignment operator (operator=) and a destructor. If you provide alternate versions of any of these functions for your class, C++ will not provide a default version. However, in C++11, you can now specify that you would like the compiler to provide a default one anyway. This is done by prototyping the function and using the default specifier:

class Foo
{
    Foo(int x); // Custom constructor
    Foo() = default; // The compiler will now provide a default constructor for class Foo as well
};

The default specifier can only be used with functions that have a default.

delete

More useful than the default specifier is the delete specifier, which can be used to disallow a function from being defined or called. One of the best uses of the delete specifier is to make a class uncopyable:

class Foo
{
    Foo& operator=(const Foo&) = delete; // disallow use of assignment operator
    Foo(const Foo&) = delete; // disallow copy construction
};

The delete specifier can also be used to make sure member functions with particular parameters aren’t called. For example:

class Foo
{
    void Foo(long long); // Can create Foo() with a long long
    void Foo(long) = delete; // But can't create it with anything smaller
};

In the above example, if you try to call Foo with a char, short, int, or long, those will all get implicitly converted to a long, which will then match Foo(long). Since Foo(long) has been deleted, the compiler will error.

If you want your class to only be called with very specific data types, you can turn off implicit conversions altogether by using a templated function to match everything that isn’t defined explicitly:

class Foo
{
    void Foo(long long); // Can create Foo() with a long long
    template<typename T> void Foo(T) = delete; // But can't create it with anything else
};

Index

B.5 — Delegating constructors

In C++03, there are often cases where it would be useful for one constructor to call another constructor in the same class. Unfortunately, this is disallowed by C++03. Commonly this ends up resulting in either duplicated code:

C++03 has partial support for initializer lists, allowing you to use initializer lists for simple aggregate data types (structs and C-style arrays):

However, this doesn’t work . . . → Read More: B.4 — Initializer lists and uniform initialization]]> Initializer lists

C++03 has partial support for initializer lists, allowing you to use initializer lists for simple aggregate data types (structs and C-style arrays):

struct Employee
{
    int nID;
    int nAge;
    float fWage;
};

Employee sJoe = {1, 42, 60000.0f};
int anArray[5] = { 3, 2, 7, 5, 8 };

However, this doesn’t work for classes, as classes must be initialized via constructors using the function call syntax. This leads to the following inconsistency:

int anArray[5] = { 3, 2, 7, 5, 8 }; // ok
std::vector<int> vArray[5] = {3, 2, 7, 5, 8}; // not okay in C++03

C++11 extends initializer lists so they can be used for all classes. This is done via a new template class called std::initializer_list, which is part of the <initializ_list> header file. If you use an initializer list on a class, C++11 will look for a constructor with a parameter of type std::initializer_list.

std::vector<int> vArray[5] = {3, 2, 7, 5, 8}; // calls constructor std::vector<int>(std::initializer_list<int>);

All of the relevant standard library classes in C++11 have been updated to accept initializer lists, so you can start using them immediately (assuming your compiler supports them — as of the time of writing, Visual Studio 2010 does not).

You can also add initializer_list constructors to your own classes, and use an iterator to step through the members of the initializer list:

#include <vector>
#include <initializer_list>

using namespace std;

template <typename T>
class MyArray
{
private:
    vector<T> m_Array;

public:
    MyArray() { }

    MyArray(const initializer_list<T>& il)
    {
        // Manually populate the elements of the array from initializer_list x
        for (auto x: il) // use range-based for statement to iterate over the elements of the initializer list
            m_Array.push_back(x); // push them into the array manually
    }
};

int main()
{
    MyArray<int> foo = { 3, 4, 6, 9 };
    return 0;
}

Because std::vector has an initializer_list constructor in C++11, we could also have let the vector constructor handle initialization itself:

    MyArray(const std::initializer_list<T>& x): m_Array(x) // let vector constructor handle population of mArray
    {
    }

Note that because initializer_list has iterator functions begin() and end(), we can use the new range-based for statement to iterate through them.

A few oddities to note: while initializer_list supports the iterator functions begin() and end(), it doesn’t support const interator functions cbegin() and cend(). Initializer_list also doesn’t provide direct random access to data members via operator[].

You can also use initializer lists a function parameters, and access the elements in the same way:

int sum(const initializer_list<int> &il)
{
    int nSum = 0;
    for (auto x: il) // use range-based for statement to iterate over the elements of the initializer list
        nSum += x;
    return nsum;
}

cout << sum( { 3, 4, 6, 9 } );

Uniform initialization

As noted above, C++03 is inconsistent in how it lets you initialize different types of data. Initializer lists go a long way to helping making initialization of data more consistent. However, C++11 has one more trick up its sleeve called uniform initialization. Unlike initializer lists, which take the form:

type variable = { data, elements };

The uniform initialization syntax takes the following form:

type variable { data, elements }; // note: no assignment operator

This style of initialization will work for both plain aggregate data types (structs and C-style arrays) and classes. For classes, the following rules are observed:

• If there is an initialization_list constructor of the appropriate type, that constructor is used
• Otherwise the class elements are initialized using the appropriate constructor

For example:

class MyStruct
{
private:
    int m_nX;
    float m_nY;

public:
    MyStruct(int x, float y): m_nX(x), m_nY(y) {};
};

MyStruct foo {2, 3.5f};

Since MyStruct does not have an initializer_list constructor, it will next check to see if there’s a constructor that takes parameters of type (int, float). MyStruct does, so that constructor is called.

Although it may initially seem like the uniform initialization syntax is always preferable to the standard constructor syntax, there are cases where the two can provide different results:

std::vector<int> v1(8); // creates an empty vector of size 8, using the int constructor
std::vector<int> v1{8}; // creates a one-element vector with data value 8, using the initializer_list constructor

This happens because the initializer_list constructor takes precedence over other constructors when doing uniform initialization.

You can also use the uniform initialization syntax when calling or return values in functions:

void useMyStruct(MyStruct x)
{
}

useMyStruct({2, 3.5f}); // use uniform initialization to create a MyStruct implicitly

MyStruct makeMyStruct(void)
{
    return {2, 3.5f}; // use uniform initialization to create a MyStruct implicitly
}

Initializer lists vs initialization lists

The choice of the name “initializer list” is unfortunate, as it’s very easy to get confused with the “initialization list”, which is a similar concept. Here’s the difference:

An initialization list is used to do implicit assignments to class variables as part of a constructor:

    MyStruct(int x, float y): m_nX(x), m_nY(y) {}; // m_nX and m_nY are part of the initialization list

An initializer list is a list of initializers inside brackets ( { } ) that can be used to initialize simple aggregate data types and classes that implement std::initializer_list:

std::vector<int> vArray[5] = {3, 2, 7, 5, 8}; // vArray initialized using an initializer_list

B.5 — Delegating constructors

Index

B.3 — Range-based for statements and static_assert

In C++03, stepping through all the values of a sequence requires a lot of code, particularly when using the iterator syntax:

In C++11, the auto keyword makes this a little better:

But this . . . → Read More: B.3 — Range-based for statements and static_assert]]> Range-based for statements

In C++03, stepping through all the values of a sequence requires a lot of code, particularly when using the iterator syntax:

for (std::vector<int>::iterator itr = myvector.begin(); itr != myvector.end(); ++itr)

In C++11, the auto keyword makes this a little better:

for (auto itr = myvector.begin(); itr != myvector.end(); ++itr)

But this is such a common pattern that C++11 has introduced an even simpler syntax to allow us to iterate through sequences, called a range-based for statement (or sometimes called “for each”):

for (auto x: myvector) // x is read-only
{
    cout << x;
}

You can translate this as “for each value of x in myvector”.

If you want to modify the value of x, you can make x a reference

for (auto& x: myvector) // x is modifiable
{
    cout << ++x;
}

This syntax works for C-style arrays and anything that supports an iterator via begin() and end() functions. This includes all standard template library container classes (including std::string) and initialization_list (which we’ll cover in the next lesson). You can also make it work for your custom classes by defining iterator-style begin() and end() member functions. If you’re using an older class that doesn’t support begin() and end() member functions, you can write free standing begin(x) and end(x) functions and this syntax will still work.

static_assert

C++03 provides an assert macro that allows testing for assertions at runtime. However, for templated programming, it’s sometimes useful to be able to test assertions at compile type. C++11 provides a new keyword called static_assert that does a compile-time assertion test.

This allows you to do things like ensure the size of variables are what you expect:

static_assert(sizeof(int) >= 4, "int needs to be 4 bytes to use this code");

Note that because static_assert is checked at compile time, it can not be used to evaluate assumptions that depend on runtime values. Static_asserts is primarily useful for checking the size of things via sizeof() or determining that #defined values are within certain boundaries.

One of the most useful things you can do with static_assert is assert on whether your compiler supports C++11 by checking whether the value of __cplusplus is greater than 199711L:

static_assert(__cplusplus > 199711L, "Program requires C++11 capable compiler");

You may wonder whether it’s redundant to check __cplusplus since compilers that don’t support static_assert will throw a compiler error when they reach the static_assert line. The answer is that it is not redundant, as many compilers (including Visual Studio 2010) have partial support for C++11 and may understand static_assert without having a full C++11 implementation. As of the time of writing, Visual Studio 2010 is in this case: it understands static_assert, but it leaves __cplusplus set to 199711L, because it’s implementation of C++11 is still pretty sparse.

B.4 — Initializer lists and uniform initialization

Index

B.2 — Long long, auto, decltype, nullptr, and enum classes

In you recall from lesson 2.4 — Integers, the largest integer type C++03 defines is “long”. Long has a platform-specific size that can be either 32 or 64 bits. C++ defines a new type named long long that’s guaranteed to be at least 64 bits in length. Because “long long” was . . . → Read More: B.2 — Long long, auto, decltype, nullptr, and enum classes]]> Type long long

In you recall from lesson 2.4 — Integers, the largest integer type C++03 defines is “long”. Long has a platform-specific size that can be either 32 or 64 bits. C++ defines a new type named long long that’s guaranteed to be at least 64 bits in length. Because “long long” was already introduced by C99, many compilers already supported it prior to C++11.

Strangely enough, although C++11 imported long long from C99, they opted not to import fixed-width integers.

Type inference with auto and decltype

My favorite change in C++11 is the introduction of the auto keyword. Consider the common use case where you want to iterate through a vector using a for loop:

for (std::vector<int>::const_iterator itr = myvector.cbegin(); itr != myvector.cend(); ++itr)

Having to determine that the data type for the iterator itr is “std::vector::const_iterator” is both a pain to get correct and obnoxious considering that the compiler already knows that the return type from cbegin() is std::vector::const_iterator — but it makes you type it out anyway.

That’s where the auto keyword comes in:

for (auto itr = myvector.cbegin(); itr != myvector.cend(); ++itr)

The auto keyword tells the compiler to infer the type of the variable from its initializer.

auto x = 5; // x will be type int
auto y = 5.5; // y will be type double
auto z = y; // z will be type double
auto w = "hi"; // w will be type const char*

The decltype can be used to determine the type of an expression at compile-type.

decltype(5) x; // x will be type int because 5 is an int
decltype(x) y = 6; // y will be type int because x is an int
auto z = x; // z will type type int

Although it may seem like auto and decltype will always deduce the same type, that isn’t the case, as shown by the following example:

const std::vector<int> v(5); // declare a vector v
auto a = v[0]; // a will be type int because v[0] is an int
decltype(v[0]) b = 1; // b will be type const int&, which is the return type of std::vector<int>::operator[](size_type) const

Generally, if you need a type for a variable you are going to initialize, use auto. decltype is better used when you need the type for something that is not a variable, like a return type.

Type nullptr

In previous iterations of C and C++, 0 acted as both a constant integer and as the null pointer constant, which is why the following oddity occurs:

int *p = 1; // illegal, can't assign an int to an int* variable
int *q = 0; // legal, 0 has a special meaning as a null pointer

C++11 defines a new reserved identifier called nullptr (of type nullptr_t) that is not an integer, and can not be converted to an integer (though oddly enough, it can be converted to the boolean value false). 0 remains a valid null point constant for backwards compatibility purposes.

Enum classes

(Note: The following isn’t yet supported by Visual Studio 2010, but it’s simple enough to follow even without trying the examples yourself)

In C++03, enums are not type safe — they are treated as integers even when the enumeration types are distinct. Consider the following case:

#include <iostream>
using namespace std;

int main()
{
    enum Color
    {
        RED,
        BLUE
    };

    enum Fruit
    {
        BANANA,
        APPLE
    };

    Color a = RED;
    Fruit b = BANANA;

    if (a == b) // The compiler will compare a and b as integers
        cout << "a and b are equal" << endl; // and find they are equal!
    else
        cout << "a and b are not equal" << endl;

    return 0;
}

When C++ compares a and b, it’s comparing them as integers, which means in the above example, a does equal b since they both default to integer 0. This is definitely not as desired since a and b are from different enumerations!

C++11 defines a new concept, the enum class, which makes enums both strongly typed and strongly scoped.

int main()
{
    enum class Color
    {
        RED,
        BLUE
    };

    enum class Fruit
    {
        BANANA,
        APPLE
    };

    Color a = Color::RED; // note: RED is not accessible any more, we have to use Color::RED
    Fruit b = Fruit::BANANA; // note: BANANA is not accessible any more, we have to use Fruit::BANANA

    if (a == b) // compile error here, as the compiler doesn't know how to compare different types Color and Fruit
        cout << "a and b are equal" << endl;
    else
        cout << "a and b are not equal" << endl;

    return 0;
}

With normal enums, you can access enumerators (eg. RED) directly in the surrounding scope (eg. within main). However, with enum classes, the strong scoping rules mean you have to use a scope qualifier to access the enumerator (eg. Color::RED). This helps keep name pollution and the potential for name conflicts down.

The strong typing rules means that C++ will look for an explicitly defined comparison function to compare Color and Fruit. Since we haven’t defined an operator==(Color, Fruit) function, the compiler won’t understand how to compare a and b in any meaningful way, and this will cause a compile-time error to occur.

B.3 — Range-based for statements and static assert

Index

B.1 — Introduction to C++11

On August 12, 2011, the ISO (International Organization for Standardization) approved a new version of C++, called C++11. C++11 adds a whole new set of features to the C++ language! Use of these new features is entirely optional — but you will undoubtedly find some of them helpful. We will only . . . → Read More: B.1 — Introduction to C++11]]> What is C++11?

On August 12, 2011, the ISO (International Organization for Standardization) approved a new version of C++, called C++11. C++11 adds a whole new set of features to the C++ language! Use of these new features is entirely optional — but you will undoubtedly find some of them helpful. We will only cover a portion of the new features here (those you are mostly likely to actually use).

Note that because C++11 is new (as of the time of writing), only modern compilers support it, and most of them only support it partially. I’ll be using Visual Studio 2010 Express Edition for sample code. Compatibility with other compilers may vary. If you are using an older version of Visual Studio, now’s a good time to upgrade to Visual Studio 2010 Express, even though it’s support for C++11 is spotty at best at the time of writing.

The goals and designs of C++11

Bjarne Stroustrup characterized the goals of C++11 as such:

• Build on C++’s strengths — rather than trying to extend C++ to new areas where it may be weaker (eg. Windows applications with heavy GUI), focus on making it do what it does well even better.
• Make C++ easier to learn, use, and teach — provide functionality that makes the language more consistent and easier to use.

To that end, the committee that put the language together tried to obey the following general principles:

• Maintain stability and compatibility with older versions of C++ and C wherever possible. Programs that worked under C++03 should generally still work under C++11.
• Keep the number of core language extensions to a minimum, and put the bulk of the changes in the standard library (an objective that wasn’t met very well with this release)
• Focus on improving abstraction mechanisms (classes, templates) rather than adding mechanisms to handle specific, narrow situations.
• Add new functionality for both novices and experts. A little of something for everybody!
• Increase type safety, to prevent inadvertent bugs.
• Improve performance and allow C++ to work directly with hardware.
• Consider usability and ecosystem issues. C++ needs to work well with other tools, be easy to use and teach, etc…

Since C++11 isn’t a large departure from C++03, it really doesn’t need any more introduction. We’ll just dive right into the new features in the next lesson.

B.2 — Long long, auto, decltype, nullptr, and enum classes

Index

A.6 — Fixed-width integers

The C99 standard defines a set of integer types that have predetermined sizes, so you don’t have to worry about the size of an integer changing if you move to another platform.

The fixed width integer types defined in C99 are named as follows:

I updated the site software today, including the primary software and a bunch of plugins. So far everything seems to be working great but it’s very possible that something has gone awry somewhere.

If you discover anything that seems wonky, please leave a message on this thread and I’ll look into it.

For those of you who are curious as to what happened, the forums have been under attack by bots for . . . → Read More: This is why we can’t have nice things]]> As you may have noticed, the site has been down for the last 5 days. The good news is that we’re back up (obviously), and things should stay that way now that they’re resolved.

For those of you who are curious as to what happened, the forums have been under attack by bots for a while now. Those bots, which previously relegated themselves to posting spam and other garbage, recently started posting content that is illegal in the country hosting this site (I’ll leave it to your imagination as to what that might be). That content got flagged by automated search agents that monitor the internet for the proliferation of such content, and our web host suspended the account.

Now that we’ve got things all cleaned up, we’re up and running again, minus the forums. Those will not be coming back. I don’t anticipate any further interruptions in service, although anything is possible.

Thanks for your patience, as always.