Is there a way to tell if a variable is uninitialized/has no value?

[irishScott]

^^^^^^^

ie:
char* asdf;

Calling delete on such an item produces run-time errors up the arse.

 

[Schadenfroh]

nevermind

 

[DaveSimmons]

In general, no.

Some compilers or add-on tools for them will either initialize all heap/stack to 0 (= null) or to some magic number, but this is usually only done for debug builds.

Bounds Checker for Visual Studio 6 did a special build of your code that inserted extra checking into all memory accesses but running under BC was about 1/10 of normal speed.

 

[SunnyD]

Um...

In general, just get in the practice of initializing every variable you declare? Every single pointer instance I declare I generally assign to NULL right off the bat, and every time a free a pointer I get in the habit of reassigning it to NULL once it's been freed. eg:

if(asdf != NULL)
{
delete asdf;
asdf = NULL;
}

 

[Markbnj]

Originally posted by: irishScott
^^^^^^^

ie:
char* asdf;

Calling delete on such an item produces run-time errors up the arse.

Heh, sorry, I found that a little funny. Yes, calling delete on such an item is guaranteed to cause a problem, but initialization is not the answer to that specific problem (despite being good practice... hell, required to demonstrate competency in my opinion).

So..

char* asdf = null;
char* asdf = "Don't delete me";
char* asdf = (char*)malloc(10);

None of those are safe to call delete on, despite having been properly initialized. Actually, the last example might be delete safe, but really you should use free().

The specific answer to your problem is that by program termination delete should be called for every variable that was initialized through the new operator. That's why it is so important to take control of the lifecycle of allocated objects using constructors and destructors.

 

[QuixoticOne]

The thing that drives me sort of crazy at times is when you initialize something to, say, NULL, at the point of declaration at the beginning of a block / function then you actually have code somewhere that loads the variable to a useful value. Then you get a compiler error / warning telling you that the variable was initialized or had a value set that wasn't actually used. You can't win either way, in a sense, depending on your compiler / options.

char *foo = NULL;
....
foo = &bar;

Error/Warning.....

 

[programmer]

Yeah, get into the practice of always assigning values to pointers at declaration, including null. In C++ this is perfectly legal:

char* foo = 0; // or null or NULL
delete foo; // no problem

No problem there, but leaving it undefined will most definitely crash:

char* foo;
delete foo; // BOOM because foo is pointing to some random memory address

 

[EagleKeeper]

Originally posted by: programmer
Yeah, get into the practice of always assigning values to pointers at declaration, including null. In C++ this is perfectly legal:

char* foo = 0; // or null or NULL
delete foo; // no problem

No problem there, but leaving it undefined will most definitely crash:

char* foo;
delete foo; // BOOM because foo is pointing to some random memory address

delete foo; // no problem

I am suprised at this. There has been no memory assigned - are compilers designed to know that NULL (0) is not a value?

I will always test for NULL before a delete is executed

 

[iCyborg]

There's no need to check for NULL when deleting:
http://www.parashift.com/c++-f...ore-mgmt.html#faq-16.8

Yes, it's a compiler thing and there might be some old and obscure one that would do something bad.

 

[Markbnj]

Originally posted by: iCyborg
There's no need to check for NULL when deleting:
http://www.parashift.com/c++-f...ore-mgmt.html#faq-16.8

Yes, it's a compiler thing and there might be some old and obscure one that would do something bad.

I stand corrected, but I wish the standard was to throw an exception rather than eat the null pointer silently. Are there cases where a properly designed and functioning program needs to delete a null pointer?

 

[iCyborg]

Not sure what you mean. Since it's effectively a no-op, it's never needed explicitly. But it's not uncommon that one doesn't know whether a pointer is null or not when deleting it.
And I like it this way, many people do "if (p!=null) delete p;", but I've never seen "else throw..."

 

[Markbnj]

Originally posted by: iCyborg
Not sure what you mean. Since it's effectively a no-op, it's never needed explicitly. But it's not uncommon that one doesn't know whether a pointer is null or not when deleting it.
And I like it this way, many people do "if (p!=null) delete p;", but I've never seen "else throw..."

Well, you would see "else throw..." if the pointer should not be null at that point in the program execution. If the programmer doesn't know whether the pointer is null, as you suggest, then there's no reason to throw an exception. Obviously either state is acceptable.

I'll have to go back and look at some of my old code and see how often I used that "if (p) delete p;" pattern. By old I mean > 10 years. I've been using structured exception handling for so long that the pattern looks cumbersome to me now. Why would a pointer be null when you delete it? The allocation failed, the allocation was never performed, the object was deleted somewhere else?

I can see using it in the clean-up from a failed ctor when you want to group a bunch of deletes together and don't know which allocation blew up. But even then I'd rather it be explicit.

 

[EagleKeeper]

I have always used the if (ptr != NULL) delete ptr; pattern by habit.

When working with pointers that need to be deleted but could be deleted elsewhere and not cleaned up properly, I will place them within a try/catch to protect the code.

 

[iCyborg]

Originally posted by: Markbnj
Well, you would see "else throw..." if the pointer should not be null at that point in the program execution. If the programmer doesn't know whether the pointer is null, as you suggest, then there's no reason to throw an exception. Obviously either state is acceptable.

Yes, I agree. I'm just saying that since I've never seen it, presumably it's much more common not to care about null, so I prefer that the c++ standard is to "silently eat the null pointer".

I'll have to go back and look at some of my old code and see how often I used that "if (p) delete p;" pattern. By old I mean > 10 years. I've been using structured exception handling for so long that the pattern looks cumbersome to me now. Why would a pointer be null when you delete it? The allocation failed, the allocation was never performed, the object was deleted somewhere else?

The most common case I see is a large class with a default constructor. For the reasons from the OP, the member pointers are set to null in the initializer list. And in the destructor I guess it's mostly just a safeguard to check for null, as the user might not have called functions that had set them to something, or they failed. And there are some legit cases where some members aren't being used for all objects at all times and all the cleanup is in the destructor.

 

[Markbnj]

The most common case I see is a large class with a default constructor. For the reasons from the OP, the member pointers are set to null in the initializer list. And in the destructor I guess it's mostly just a safeguard to check for null, as the user might not have called functions that had set them to something, or they failed.

Yep, I agree. In that particular case I would throw an exception from the constructor at the point where the allocation failed, catch it locally and clean up the already-allocated pointers, and then rethrow. In cleaning up the pointers I would explicitly check for null (since they would have been initialized). Just anal I guess.