Game Development Reference
In-Depth Information
std::string s((str))
pErrorMessenger->Show(s, false, __FUNCTION__, __FILE__, __LINE__);
}; // <-- NOTICE THE SEMICOLON HERE!!
else
DoSomethingGood();
The semicolon after the
if
block closes that
if
statement, so the
else
is illegal. You
could solve it by removing the semicolon from the call, like this:
if (fail)
GCC_ERROR(
“
Fail
”
) // no semicolon
else
DoSomethingGood();
This creates inconsistent code and calling conventions. Using the
do...while(0)
trick solves this problem completely since the semicolon is now just ending the
while
loop. The compiler is smart enough to know that
while(0)
will never loop,
so it doesn
t bother checking to see if it needs to go back. The performance is exactly
the same. In fact, it generates the exact same assembly code.
The other debug and logging macros work in a similar fashion. They are all defined
in Dev\Source\GCC4\Debugging\Logger.h. You can find the rest of the logging code
in Dev\Source\GCC4\Debugging\Logger.cpp.
'
Tactics and technique are great, but that only describes debugging in the most
generic sense. You should build a taxonomy of bugs, a dictionary of bugs as it were,
so that you can instantly recognize a type of bug and associate it with the beginning
steps of a solution. One way to do this is to constantly trade
“
”
stories with other
programmers
—
a conversation that will bore nonprogrammers completely to death.
bug
A memory leak is caused when a dynamically allocated memory block is
The
pointer that holds the address of the block is reassigned without freeing the block,
and it will remain allocated until the application exits. This kind of bug is especially
problematic if this happens frequently. The program will chew up physical and vir-
tual memory over time, and eventually it will fail. Here
“
lost.
”
s a classic example of a mem-
ory leak. This class allocates a block of memory in a constructor but fails to declare a
virtual destructor:
'
class LeakyMemory : public SomeBaseClass
{