views:

382

answers:

6

When do we need to use "assert" for pointers in C++, and when they are used, how are they most commonly implemented?

+9  A: 

Generally you would use an assert to check a condition that, if false, would indicate a bug in your application. So if a NULL pointer shouldn't ever be encountered at some point in the application, unless there's a bug, then assert it. If it might be encountered due to some invalid input then you need to do proper error handling.

Evgeny
If a pointer should never be null, then you might want to think about turning it into a reference (if possible, of course).
Luc Touraille
+5  A: 

You don't need to use assert on pointers at all. The idea is to ensure you don't crash when dereferencing your pointers when they're null.

You can do this with assert but it's not a very professional way to handle errors like this since it invariably terminates the program - not a good idea if the user hasn't, for example, saved their last three hours worth of data entry.

What you should do with pointers is to check them for null-ness and fail gracefully. In other words, have your function return an error of some sort or do nothing (not everyone will agree with this approach but it's perfectly acceptable if it's documented).

The assert stuff is meant, in my opinion, for catching problems during development which is why you'll find assert does nothing in release builds under some compilers. It is not a substitute for defensive programming.

As to how to do it:

#include <assert.h>
void doSomethingWithPointer (int *p) {
    assert (p != 0);
    cout << *p << endl;
}

but this would be better done as:

void doSomethingWithPointer (int *p) {
    if (p != 0)
        cout << *p << endl;
}

In other words, even if your "contract" (API) states that you're not allowed to receive null pointers, you should still handle them gracefully. An old quote: be conservative in what you give, liberal in what you accept (paraphrased).

paxdiablo
On the other hand, crashing and losing 3 hours of the user's work is preferable to trying to "work around" a problem and corrupting 3 weeks of it.
Anon.
@Anon, I believe that would be covered by the "gracefully" bit :-) Obviously you have to do it *right*. Asserts won't help your software in the field one tiny little bit if they've been disabled in non-debug code. Asserts are for development, not production (unless you're one of those types that only ever sends debug code out to the field anyway).
paxdiablo
That's where macros come in handy: assert may produce a core in debug mode and an exception in release mode :)
Matthieu M.
+3  A: 

ASSERT statements are great as "enforced documentation" - that is, they tell the reader something about the code ("This should never happen") and then enforces it by letting you know if they don't hold true.

If it's something that could happen (invalid input, memory not able to be allocated), that's not a time to use ASSERT. Asserts are only for things that can not possibly happen if everyone is obeying pre-conditions and such.

You can do it thusly:

ASSERT(pMyPointer);
Smashery
(In case anyone is wondering, the allcaps `ASSERT` is the Microsoft assert macro, and lowercase `assert` is Standard C.)
Jason Orendorff
A: 

I would use an ASSERT where a null pointer wouldn't immediately cause a crash but might lead to somethign wrong later that's hard to spot.
eg:

ASSERT(p);   
strcpy(p, "hello");

Is a little unnecessary, it simply replaces a fatal exception with a fatal assert!
But in more complex code, particulalrly things like smart pointers, it might be useful to know check if the pointer is what you thing it is.

Remember ASSERTs only run in debug builds, they dissapear in the release.

Martin Beckett
+1  A: 

From experience if you assert on null conditions that should never happen under normal conditions you program is in a really bad state. Recovering from such null condition will more likely than not mask the original problem.

Unless you code with exception guarantee in mind (linky) I say let it crash, then you know you have a problem.

Igor Zevaka
I would say: "should never happen under any conditions".
Thomas Padron-McCarthy
A: 

In C, there also assert function.. in debug mode, if assert(x), x condition is false, there will pop up an alert... But remember it works only in debug mode... in release mode, all assert functions are all skipped

Macroideal