Reputation: 61
This is my first attempt to write a custom exception class implementing a simple form of stack-trace.
This is the .h:
class error {
public:
error ();
error (const error & err);
~error ();
int level ();
private:
int _level;
};
And this is the .cpp:
error::error ()
: _level (0) {}
error::error (const error & err)
: _level (err._level) {}
error::~error () {}
int error::level () {
return ++_level;
}
Then I define two macros, one to create an error and throw it the first time (INIT_ERROR), and the other to kick the catched errors (KICK_ERROR):
#define WHERE(stream) {fprintf (stream, " %-30s [%s: %3d]\n", __FUNCTION__, __FILE__, __LINE__);}
#define INIT_ERROR {fprintf (stderr, "# 0"); WHERE (stderr); throw error ();}
#define KICK_ERROR {fprintf (stderr, "# %2d", err.level ()); WHERE (stderr); throw;}
As you expect, the use is as follow:
if (something wrong)
INIT_ERROR;
for the first time, and:
try {
// some code
}
catch (error & err) {
KICK_ERROR;
}
for all the other times.
However, DrMemory (I'm working on Windows Xp), alert me about still reachable blocks:
ERRORS FOUND:
0 unique, 0 total unaddressable access(es)
0 unique, 0 total uninitialized access(es)
0 unique, 0 total invalid heap argument(s)
0 unique, 0 total GDI usage error(s)
0 unique, 0 total warning(s)
0 unique, 0 total, 0 byte(s) of leak(s)
0 unique, 0 total, 0 byte(s) of possible leak(s)
3 unique, 3 total, 16 byte(s) of still-reachable allocation(s)
ERRORS IGNORED:
3 potential leak(s) (suspected false positives)
For completeness, this is the main:
void fun3 () {
fprintf (stderr, "nothing special");
INIT_ERROR;
}
void fun2 () {
try {
fun3 ();
}
catch (error & err) {
KICK_ERROR;
}
}
void fun1 () {
try {
fun2 ();
}
catch (error & err) {
KICK_ERROR;
}
}
int main () {
try {
fun1 ();
}
catch (error & err) {
cerr << "error catched in main" << endl;
}
}
Is this something wrong in my code? Suggestions?
Upvotes: 2
Views: 163
Reputation: 33516
I don't think that there are any leaks. Your code seems valid. I think that the three blocks are just the allocated objects that were still alive at the precise point of time when program was starting its cleanup-on-death, if you might call that so.
I mean, something trivial like, std::cout, your exception and some lingering temporary string ;)
If you'd like to verify that, add a top-level TRY/CATCH at the most outer scope od MAIN that calls your exception test, so that the exception will be actually caught, stack unwound and so that the program will exit normally. That way, after catch/unwind, the lingering exception object and other should be cleaned up and probalby you will see LESS still-reachables.
Not necessarily zero, that depends on libraries used and the way that "DrMemory" of yours account for CRT "baseline memory footprint", sorry I don't know how to call that better..
Upvotes: 0
Reputation: 6145
Still reachable allocations are not leaks, this is memory that is still available to the program at exit. It might be allocated from the libraries you use. I would not worry about them.
Upvotes: 1