How to catch error when deleting a pointer?

[Bezi]

I have a piece of code, where at some point I need to delete a pointer to get sure that the memory is freed. However, sometimes the memory for this pointer is not allocated with "new" command, so I wrote the following exception handling to bypass this situation.

try {
	delete ptr;
} catch (...) {
	std::cout << "ptr cannot be deleted" ;
}

However it seems that this is not capable of catching the error and the program is aborted. What am I doing wrong in here?

[Moschops]

C++ 98 standard states (excerpt from 3.7.3.2, paragraph 3:

The value of the first argument supplied to one of the deallocation functions provided in the standard
library may be a null pointer value; if so, the call to the deallocation function has no effect.

If you pass it a null pointer, nothing happens. No exception is thrown.

C++ 98 standard states (excerpt from 3.7.3.2, paragraph 4:

If the argument given to a deallocation function in the standard library is a pointer that is not the null pointer value (4.10), the deallocation function shall deallocate the storage referenced by the pointer, rendering invalid all pointers referring to any part of the deallocated storage. The effect of using an invalid pointer value (including passing it to a deallocation function) is undefined.33)

The effect of passing delete something that is not a valid pointer is undefined. It could do anything. How do you know it's throwing an exception for you to catch?

[Bezi]

so what should I do in this situation?

I need to delete the pointer to avoid memory leak, but sometimes during the code run it "may" be the case that memory to the pointer is no allocated with "new", so deleting it would crash the code.

[quirkyusername]

when you say it's not always allocated with new, do you mean that you use malloc, or that the data is created on the stack and then a pointer is set to point at it, or that sometimes the variable isn't allocated any memory at all?

If the memory is created on the stack with another variable then you don't need to delete the pointer because the memory will be deallocated when the original variable goes out of scope.

If you're using malloc...you probably shouldn't. I can't think of any reason to use it in c++ other than when you overload new, correct me if I'm wrong.

And if it doesn't get allocated any memory at all, initialise the pointer to 0 and then check whether it's 0or not before deciding whether to delete it

[Bezi]

If it's created on the stack then you don't need to delete the pointer because the memory will be deallocated when the original variable goes out of scope

I know, and I am not using malloc

this is sort of the situation:
I pass a pointer to a function, under some circumstances the function needs to dispose the pointer,
but it can be the case that the pointer sent to the function is created on the stack. so crash!

[quirkyusername]

well then decide on one way of allocating memory which will be passed into that function. Is there a real need to use both?

[Disch]

You have a design problem.

If you own this pointer, then you know whether or not it was allocated with new. And if you do not own it, you should not be deleting it.

Passing ownership is very ill advised because it leads to these kinds of problems and worse (memory leaks, maintanace issues, pointers being deleted before you're done with them, etc)

You're passing responsibility to an area of the program which doesn't have enough information to manage that responsibility. This is a design flaw.


The solution here is to not do what you're doing. Instead, make a clear distinction about who owns what pointer. Whoever the owner is should be the one who deletes it. Note that most likely, the owner is whatever allocated it in the first place.

[simeonz]

One valid situation where you may want to do this is if you try to implement garbage collection and you want to discriminate pointers on the heap from pointers on the stack.

Well, basically, you can not. You can, but you have to replace (provide your own definition) of the global new, new[], delete, delete[] operators and the std::nothrow variants. First, this is a bulk of functions. Second, implementing them with malloc is not entirely easy, because they have complex default behavior. Third, something else you use may try to replace them too.

However, if you decide to go that way, you could create a set/map and fill it with the blocks of memory that have been allocated using new and new[], sorted according to their starting address. Even so, searching in this tree is going to be too slow for a function that is supposed to perform mere resource de-allocation.

Regards

[quirkyusername]

Can you explain your problem in more detail, you haven't mentioned the aim of your program or how it is structured, what the different components are and how they access each other etc. Bed-time for me but someone else will answer, Disch is a genius.

[Bezi]

If there is no exception handling in this situation then I believe the only possible solution would be to change the design to avoid this situation.
Thanks guys for replies

[Moschops]

Exceptions are, as their name implies, for exceptional circumstances*. It is in no way exceptional that you are expected to keep track of memory you have manually allocated.

*Please, please; let's not have a war about what circumstances are and are not exceptional :)

[simeonz]

Moschops wrote:

It is in no way exceptional that you are expected to keep track of memory you have manually allocated.

Depends on the point of view.

Moschops wrote:

Please, please; let's not have a war about what circumstances are and are not exceptional :)

Sorry :)

[coder777]

If there is no exception handling in this situation then I believe the only possible solution would be to change the design to avoid this situation.
Thanks guys for replies

Not necessarily. You can pass another paramter that tells whether to delete the pointer or not.

[Bezi]

Exceptions are, as their name implies, for exceptional circumstances*. It is in no way exceptional that you are expected to keep track of memory you have manually allocated.

I am sure you can come up with an example that can be implemented either by exception handling or alternatively by keeping track of some extra stuff. so Exceptions are not always exactly as you described

*Please, please; let's not have a war about what circumstances are and are not exceptional :)

too late, you have already thrown down the gauntlet. :)