std::vector simple scope question

[Oliver M.]

You are right, I overlooked your statement

Depending on how the memeory is allocated/released, it might happen that the memory for the object will not get erased/claimed by the system when the 2nd someFunc is invoked.

But be honest: how many compilers and systems do you know where the memory is neither sweeped in debug mode nor the access of an unallocated memory causes a GPF or the deletion (we talk about c++ here?) is delayed? Ok, maybe here are the 1%...

I personally see more probability for the points I enumerated and prefer setting the pointers to NULL. If someone is concerned about efficiency, well, he might set it to NULL in debug builds only. Otherwise it is not worth the trouble, so I recommend to make it a habit to always set it to NULL and forget about it.

Ah, and I believe that there are other means of finding a bug like this than looking at 500K lines of code

[PadexArt]

But be honest: how many compilers and systems do you know where the memory is neither sweeped in debug mode nor the access of an unallocated memory causes a GPF or the deletion (we talk about c++ here?) is delayed? Ok, maybe here are the 1%...

This is not something that occurs very often ( indeed this is the 1%) but when it does it is really difficult to find.

Ah, and I believe that there are other means of finding a bug like this than looking at 500K lines of code

Yes, there are, but hopefully this small trick will trigger the alarm when you are confident that everything is running smoothlly.

[Oliver M.]

Right: just make it a habit to always set pointers to deleted objects to NULL and forget about it. It will not harm you (much) but might help you.

[exterminator]

Well, I know this topic has been beaten to death but I was really trying hard to figure out a case when PadexArt's suggestion could help.

.... the access of an unallocated memory causes a GPF....

There could pieces of code that someone wrote which is rarely called once in a while (1% of the time .. owing either to a strange business logic or dynamic binding). Considering the fact that the test specifications missed that particular test case where that particular source is executed, it could lead to a crash. This piece tries manipulating a deleted object and hence would be disastrous.

I know.. there should be proper exception handling and logging to handle such situations (crashes) but there can be and are exceptions to this. Regards.

[NMTop40]

The only things I can think why of setting a member pointer to NULL in the destructor are
- a generally good habit
- issues of multithreading (although it is not that safe)
- member function calls from the destructor that otherwise would attempt use the object (if these calls are added later, good habits certainly pay off).

It is far from just being "not that safe" in a multithreaded environment.

If your thread and my thread are sharing an object and my thread deletes it (thus getting into its destructor) what do you think will happen in your thread when it goes on using the object?

Actually that's a typical error to make with regards the void* parameter that's usually passed to a threading function. (Often wrongly the address of a local variable that can go out of scope at any time).

[Oliver M.]

Interesting what you read from the line "issues of multithreading (although it is not that safe)"... I meant "safe" in regards to debugging issues, nothing more.