• Choose a category
• All
• Classic-Fiction

By Root 1132 0

For example, if you call a library function that is supposed to return a pointer and claims never to return nullptr, throw in an assert after the function call to make sure that the pointer isn’t nullptr.

Note that you should assume as little as possible. For example, if you are writing a library function, don’t assert that the parameters are valid. Instead, check the parameters and return an error code or throw an exception if they are invalid.

For example, in the start-time debugging example, the function trickyFunction() takes a parameter of type ComplicatedClass*. Instead of assuming that the argument is valid, it might be a good idea to assert it like this:

void trickyFunction(ComplicatedClass* obj) throw(exception)

{

assert(obj != nullptr);

// Remainder of the function omitted for brevity

}

Be careful not to put any code that must be executed for correct program functioning inside asserts. For example, a line like this is probably asking for trouble: assert(myFunctionCall() != nullptr). If a release build of your code strips asserts, then the call to myFunctionCall() will be stripped as well.

Static Asserts

The asserts discussed in the previous section are evaluated at run time. C++11 introduces the static_assert feature, which is an assert that is evaluated at compile time.

A static_assert requires two parameters: an expression to evaluate and a string. When the expression evaluates to false, the compiler will issue an error that contains the given string. A simple example is to check INT_MAX:

static_assert(INT_MAX >= 0x7FFFFFFF,

"Code requires INT_MAX to be at least 0x7FFFFFFF.");

If you compile this with a compiler where INT_MAX is less than 0x7FFFFFFF, the compiler will issue an error that looks as follows:

test.cpp(3): error C2338: Code requires INT_MAX to be at least 0x7FFFFFFF.

Another example where static_asserts are pretty powerful is in combination with type traits. Type traits are discussed in Chapter 20. For example, if you write a function template or class template, you could use static_asserts together with type traits to issue compiler errors when template types don’t satisfy certain conditions.

The following example requires that the template type for the process() function template has Base1 as its base class:

#include

using namespace std;

class Base1 {};

class Base1Child : public Base1 {};

class Base2 {};

class Base2Child : public Base2 {};

template

void process(const T& t)

{

static_assert(is_base_of::value, "Base1 should be a base for T.");

}

int main()

{

process(Base1());

process(Base1Child());

//process(Base2()); // Error

//process(Base2Child()); // Error

return 0;

}

Code snippet from StaticAssert\StaticAssert.cpp

If you try to call the process() function template with an instance of Base2 or Base2Child, the compiler will issue an error that looks as follows:

1>test.cpp(13): error C2338: Base1 should be a base for T.

1> test.cpp(21) : see reference to function template

1> instantiation 'void process(const T &)' being compiled

1> with

1> [

1> T=Base2

1> ]

DEBUGGING TECHNIQUES

Debugging a program can be incredibly frustrating. However, with a systematic approach it becomes significantly easier. Your first step in trying to debug a program should always be to reproduce the bug. Depending on whether or not you can reproduce the bug, your subsequent approach will differ. The next three sections explain how to reproduce bugs, how to debug reproducible bugs, and how to debug nonreproducible bugs. Additional sections explain details about debugging memory errors and debugging multithreaded programs.

Reproducing Bugs

If you can reproduce the bug consistently, it will be much easier to determine the root cause. Finding the root cause of bugs that are not reproducible is difficult, if not impossible.

As a first step to reproduce the bug, run the program with exactly the same inputs as the run when the bug first appeared. Be sure to include all inputs, from the program’s startup to the time of the bug