• Choose a category
• All
• Classic-Fiction

{

os << t1;

}

template

void addEntryHelper(ostringstream& os, const T1& t1, const Tn&... args)

{

os << t1;

addEntryHelper(os, args...);

}

void addStringEntry(const string& entry);

};

Code snippet from RingBufferVariadicTemplates\RingBuffer.h

The implementation of this new RingBuffer class is identical to the first version, except for the following line:

void RingBuffer::addEntry(const string& entry)

In the new implementation, this line should be changed to:

void RingBuffer::addStringEntry(const string& entry)

This new ring buffer is used a little bit differently compared to the first version, but the result is much more readable and more compact. The new trickyFunction() implementation is as follows:

void trickyFunction(ComplicatedClass* obj) throw(exception)

{

// trace log the values with which this function starts

debugBuf.addEntry(__func__, "(): given argument: ", *obj);

for (size_t i = 0; i < 100; ++i) {

UserCommand cmd = getNextCommand(obj);

debugBuf.addEntry(__func__, "(): retrieved cmd ", cmd);

try {

processUserCommand(cmd);

} catch (const exception& e) {

debugBuf.addEntry(__func__,

"(): received exception from processUserCommand():", e.what());

throw;

}

}

}

Code snippet from RingBufferVariadicTemplates\RingBufferTest.cpp

There is no need any more for using ostringstreams or string concatenation. You can call the addEntry() variadic method template and specify as many arguments as you want. Since this is using the C++11 variadic template feature, this variable argument method is completely type-safe. Variadic templates are discussed in detail in Chapter 20.

Displaying the Ring Buffer Contents

Storing trace debug messages in memory is a great start, but in order for them to be useful, you need a way to access these traces for debugging.

Your program should provide a “hook” to tell it to print the messages. This hook could be similar to the interface you would use to enable debugging at run time. Additionally, if your program encounters a fatal error that causes it to exit, it should print the ring buffer to standard error or to a log file before exiting.

Another way to retrieve these messages is to obtain a memory dump of the program. Each platform handles memory dumps differently, so you should consult a book or expert on your platform.

Asserts

The library defines an assert macro. It takes a Boolean expression and, if the expression evaluates to false, prints an error message and terminates the program. If the expression evaluates to true, it does nothing.

You should try to avoid any library functions or macros that can terminate your program. It’s recommended to write your own assert function or macro that, for example, throws an exception, or in which you handle failed asserts in a way that suits your application, without terminating the program. However, the library is sometimes used, so you need to know about its existence.

Although the behavior of an assert may not sound particularly helpful, it turns out to be quite useful in some cases. It allows you to “force” your program to exhibit a bug at the exact point where that bug originates. If you didn’t assert at that point, your program might proceed with those incorrect values, and the bug might not show up until much later. Thus, asserts allow you to detect bugs earlier than you otherwise would. Though, as said in the previous warning, it’s highly recommended to write your own version of assert that does not terminate the application.

The behavior of the standard assert macro depends on the NDEBUG preprocessor symbol: If the symbol is not defined, the assertion takes place, otherwise it is ignored. Compilers often define this symbol when compiling “release” builds. If you want to leave asserts in release builds, you must change your compiler settings, or, as recommended, write your own version of assert that isn’t affected by the value of NDEBUG.

You could use asserts in your code whenever you are “assuming” something about the state of your variables.