A question about deleting a native pointer

[AKRichard]

So the most important question probably is: How did you allocate the object in question? Note that the C++ delete statement is not easily mappable to a single memory release runtime routine you can call from your assembly code. Also, I can't recall having seen any dynamic memory allocation calls in your assembly code at all anyway.

in this particular instance I found out the only way this piece of code ever gets hit is if the object being deleted was created in the assembly routine. The reason why you never saw the allocation was because I created a routine (in the assembly language section) to create the object. It is created dynamically since I dont know ahead of time how big to make the array. The object is created through 3 calls to malloc, as mentioned above the first call represents the _sign pointer, the second represents the _number pointer, and the third is the one that represents the this pointer. When I built the object like this in the assembly routine and returned the created object to native/managed c++, the c++ side was reading the object fine as if it had been created with the "new" operator, giving me access not only to the internal variables (both pointers) but also to the functions and properties of the class.

The this pointer as such is just a single pointer, no more, no less. And what it points to is the binary in-memory representation of your object, consisting of the fields you declared for your object, not an array of pointers to these fields.

Ive been trying to find more info into the nature of the "this" pointer. Once the object I create is back in the c++ code, I have access to the various fields AND functions and properties, but in the assembly code, I only have access to the fields, which leaves me to believe that the clr/crt maps a vtable to the object somehow, but I am not sure how it associates that vtable to the object. I can reach the functions and properties of the native class through the assembly code, but not in the context of a particular instance of the object. This also applies to instances of the native class passed into the assembly code that were created with the "new" operator thats why I mentioned I believe it is happening in the clr/crt. This is not a problem in my code, I only mention it because if I am not creating an instance of the "this" pointer that the clr/crt can understand, then it makes sense that it also wont know how to clean up the "this" pointer. After saying all this, I am thinking maybe I should try cleaning it up in the assembly code, instead of using "delete" maybe I should be calling the cleanup routine I have in assembly that I use whenever a temporary instance is created in one of the assembly language routines. Even if that works though, it seems the appropriate way would be to make sure the object created and returned by assembly code follows the rules of an object created through "new" under the clr/crt so that it could be destroyed with "delete".

Just for clarity, I know the clr uses "gcnew" for managed objects, what I am trying to follow would be just the native use of "new" and "delete"