Call to destructor crashes program

Thanks to the help from all you lovely people on my last problem I've managed to crack on and make my program work the way I wanted. :D

For a quick catchup: I have a program that creates objects on the fly with new every time a certain event happens, and stores the memory locations of these new objects in a database as an integer value. I can then interact with any specific object by converting the integer value back into a pointer. All this is working brilliantly!

However, when the object is destroyed using delete on that pointer, the destructor is called and executes all it's code correctly, then the program crashes. My compiler (Visual C++ Express) throws a message saying No Source Available with "Call stack location: Table::`scalar deleting destructor'() + 0x2b bytes".

Am I doing something wrong by calling delete on a pointer to the object?

Relevant code below. I have omitted all the database query code:

Code:

---

unsigned long tablename;
// this variable holds the memory location (in integer form)
// of a specific object, retrieved from the database.

Table* tableptr; // pointer of class type
tableptr = (Table*)tablename;
delete tableptr;

// destructor is called correctly

Table::~Table()
{
        // more database interaction code which completes successfully
}

---

This code is not enough to tell what is wrong. There is a possibility, that a completely different and irrelevant thing went wrong. I don't think that storing pointer in a data base is a good idea. Program/database may crash/quit and the values will remain and will be invalid in the next run. Also, use reinterpret_cast for int <=> pointer conversions. What is size of long? AFAIK it's always 32 bit in MSVC and as you know, pointer is 64-bit on 64-bit systems.

There are three potential problems I can see.

Firstly, there is no guarantee that a pointer value will survive a round-trip through an unsigned long (i.e. pointer -> unsigned long -> pointer is not guaranteed to give the original pointer value).

Second, even if a pointer can survive that round-trip, you will have problems if your program exits and reads from the database again, as it is not guaranteed that values in the database will correspond to any valid object created by your program when subsequently run. [And if this is not a factor, it needs to be asked why you are storing the values in a database - there are alternative options].

Third, even if the object being deleted is valid (i.e. created with operator new) the most common causes of crash when invoking a destructor or operator delete is pointer molestation. For example;

Code:

---

    Object *x = new Object;
    SomethingElse *y = NULL;
    y->MemberFunctionThatChangesASomethingElse();  // dereferencing NULL and writing to random memory here
    delete x;                                                          // crash occurs here

---

Thanks for feedback both of you. I figured there was nothing wrong with the pointers since I was able to interact with the objects, but I'll go back over the pointer conversions and make sure the byte length is correct. I had a quick look and see that there are some native typedefs designed to handle converting pointer values to int so it shouldn't be too hard.

Regarding the database, it's true that I don't need to worry about losing the contents of the memory location table, but I have to use the database for other things so it made sense at the time to keep it all in the same place. I could change the code to use a vector of a structure type that holds the object's unique ID and a pointer to it. Then I wouldn't have to worry about converting pointers at all! Would this be a better direction?

Pointers should not be visible to the user. You should store unique ID (vector's indices at least).

From 5.2.10.5:

Quote:

---

A value of integral type or enumeration type can be explicitly converted to a pointer.64) A pointer converted
to an integer of sufficient size (if any such exists on the implementation) and back to the same pointer type
will have its original value; mappings between pointers and integers are otherwise implementation-defined.

---

So, if the integer type is large enough to hold the pointer, the pointer's value will survive the 'pointer -> int -> pointer' conversion