Detecting if object on Stack in destructor
Is there any way of determining whether an object being deleted is on the stack while in the object's destrutor?
Last edited on
Not really. And if that actually matters in any way, it's quite certain that you made a serious design mistake somewhere.
I wish it was a design issue but I'm afraid I don't think it is. On the other hand, let me explain the issue and see if you can come up with an alternative.
I am implementing Weizenbaum's Symmetric List Process (SLIP) in C++ and extending it to include arithmetic operations on Slip Cells. The extension means that Slip Cells containing heterogeneous data items can be treated as primitives in arithmetic operations. That is, Cell1 + Cell2 is valid (with appropriate runtime checks and casting) as opposed to Cell1.getData and convert explicitly + Cell2.getData and convert explicitly. The issue arises that in performing arithmetic operations intermediate, temporary data is created. This temporary data is heterogeneous, just like the original data contained in the Slip Cells, and the data type (and value) must be preserved. I have elected to do this in a Slip Cell. The intermediate data Slip Cells must be deleted at the end of the computation. And that is the rub. I have chosen to create these Cells and put them on the runtime stack. The runtime system will delete these items when the local scope is exited. I could not think of a way to create the cells using the heap, sic. Slip Available Space List, and have automatic deletion of temporaries, and I couldn't think of a good way to create temporaries with heterogeneous data and have the user perform explicit deletion, plus, leaving the user to do deletion is clumsy, error prone and a strong candidate for creating memory leaks.
That's my problem. Any solutions?
I am implementing Weizenbaum's Symmetric List Process (SLIP) in C++ and extending it to include arithmetic operations on Slip Cells. The extension means that Slip Cells containing heterogeneous data items can be treated as primitives in arithmetic operations. That is, Cell1 + Cell2 is valid (with appropriate runtime checks and casting) as opposed to Cell1.getData and convert explicitly + Cell2.getData and convert explicitly. The issue arises that in performing arithmetic operations intermediate, temporary data is created. This temporary data is heterogeneous, just like the original data contained in the Slip Cells, and the data type (and value) must be preserved. I have elected to do this in a Slip Cell. The intermediate data Slip Cells must be deleted at the end of the computation. And that is the rub. I have chosen to create these Cells and put them on the runtime stack. The runtime system will delete these items when the local scope is exited. I could not think of a way to create the cells using the heap, sic. Slip Available Space List, and have automatic deletion of temporaries, and I couldn't think of a good way to create temporaries with heterogeneous data and have the user perform explicit deletion, plus, leaving the user to do deletion is clumsy, error prone and a strong candidate for creating memory leaks.
That's my problem. Any solutions?
Thanks JLBorges;
I looked at are article and will be looking at More Effective C++ tonight. I on't think the solution fits my needs and I don't think that I can change the given code to make it more suitable. If I'm reading the code right, the suggestion is to fit a wrapper around a variable and to determine during class destruction that the variables have all been gotten from the heap. My problem is that in some cases my code will get space for a class from the heap and in other cases from the runtime stack. During each class destruction I would like to determine where the data comes from. If space came from the heap, then delete the space from the heap. If space was allocated from the stack, do nothing the runtime C++ kernel will delete the space when the local scope is exited.
My (current) answer is to tag the allocation as to source, and then to limit a users ability to do anything useful if the user allocates from the stack
But thanks for the reference. It certainly gives me an opportunity to question my assumptions.
art
I looked at are article and will be looking at More Effective C++ tonight. I on't think the solution fits my needs and I don't think that I can change the given code to make it more suitable. If I'm reading the code right, the suggestion is to fit a wrapper around a variable and to determine during class destruction that the variables have all been gotten from the heap. My problem is that in some cases my code will get space for a class from the heap and in other cases from the runtime stack. During each class destruction I would like to determine where the data comes from. If space came from the heap, then delete the space from the heap. If space was allocated from the stack, do nothing the runtime C++ kernel will delete the space when the local scope is exited.
My (current) answer is to tag the allocation as to source, and then to limit a users ability to do anything useful if the user allocates from the stack
But thanks for the reference. It certainly gives me an opportunity to question my assumptions.
art
Topic archived. No new replies allowed.