valgrind sucks

[Kuciwalker]

Oh, I have. But I kind of doubt this is a compiler bug...

[Jon Miller]

Library bug than?

Can you get access to the library source?

JM

[Kuciwalker]

I have no desire to debug glibc.

[Sirotnikov]

Sidenote: This thread reminds me of one of my favourite interview questions: How should you handle a destructor that fails?

I can provide a solution if someone wants it.

I'm interested

[Kuciwalker]

So everyone knows the answer to the destructor question?

I don't believe you can provide a universally applicable answer. It depends on the application - in particular, it depends on the reason for needing the destructor in the first place.

[Asher]

I don't believe you can provide a universally applicable answer. It depends on the application - in particular, it depends on the reason for needing the destructor in the first place.

Assuming you'd like to know of the failures, there's only one way.

So, for a constructor you should throw an exception. Can't use return values, they have no return value. You could also just log it, but this isn't really helpful.

For a destructor, you cannot do a return value...obviously. You also should not under any circumstances throw an exception. The only thing you could possibly do is log it, or ignore it. Logging is preferred. The standard allows you to throw an exception, but it is very dangerous.

That's the easy answer, but in the interview the meat is the follow-up question: Why not throw an exception?.

The main problem is that it puts the C++ runtime in a bad state if an exception is thrown during the process of unwinding the stack. The stack gets unwound when code throws an exception (so "throw Blah()" will unwind the stack all the way from the throw statement to the catch statement). The process of unwinding destroys all local objects that got popped. If one of those objects throws another exception, the C++ runtime has no proper recourse. Say you do a throw Blah() and it starts unwinding objects, one of which has a destructor which throws a Blee(). At this point, it doesn't know which catch to go to. Either choice will ignore at least one catch block.

So the C++ standard defines a course of action. It calls terminate(). The app dies, period. If you didn't deallocate everything, tough ****, it's done.

If that makes sense.

It's a terrific question because it not only asks about good programming practice, but to answer the "why" question the person needs to have a pretty clear understanding of how C++ works or at least have very strong ability to reason through things, if given a couple hints.

[Asher]

Another question I'll always ask regarding destructors is: "When should your destructor be virtual, and why?"

For similar reasons to the other question.

[Kuciwalker]

Assuming you'd like to know of the failures, there's only one way.

So, for a constructor you should throw an exception. Can't use return values, they have no return value. You could also just log it, but this isn't really helpful.

For a destructor, you cannot do a return value...obviously. You also should not under any circumstances throw an exception. The only thing you could possibly do is log it, or ignore it. Logging is preferred. The standard allows you to throw an exception, but it is very dangerous.

That's the easy answer, but in the interview the meat is the follow-up question: Why not throw an exception?.

The main problem is that it puts the C++ runtime in a bad state if an exception is thrown during the process of unwinding the stack. The stack gets unwound when code throws an exception (so "throw Blah()" will unwind the stack all the way from the throw statement to the catch statement). The process of unwinding destroys all local objects that got popped. If one of those objects throws another exception, the C++ runtime has no proper recourse. Say you do a throw Blah() and it starts unwinding objects, one of which has a destructor which throws a Blee(). At this point, it doesn't know which catch to go to. Either choice will ignore at least one catch block.

So the C++ standard defines a course of action. It calls terminate(). The app dies, period. If you didn't deallocate everything, tough ****, it's done.

If that makes sense.

It's a terrific question because it not only asks about good programming practice, but to answer the "why" question the person needs to have a pretty clear understanding of how C++ works or at least have very strong ability to reason through things, if given a couple hints.

Oh, you're talking about specifically in C++land (I don't know C++). I thought it was a more general question. None of your reasoning applies to C constructors or destructors.

[Asher]

C constructors and destructors?

[Kuciwalker]

Yes.

[Asher]

Go on

[Kuciwalker]

typedef struct point_s {
	int x;
	int y;
} point_t;

// constructor
point_t* point_create(int x, int y)
{
	point_t p = malloc(sizeof(point_t));
	if (!p) return NULL;
	point_init(p, x, y);
	return p;
}

//initializer
void point_init(point_t* p, int x, int y)
{
	p->x = x;
	p->y = y;
}

etc.

[Asher]

That ain't no language construct though.

[Kuciwalker]

[Kuciwalker]

Actually, it (well, a variant of it) is a language construct in RTSC, the extension of C we use at work.