Should or can we ever put ptr-to-ptr into a smart ptr like smart_ptr?
My problem is the delete in the smart_ptr dtor — “delete ptr2ptr2dbl” where ptr2ptr2dbl is pointing at a 32-bit object (let’s call it “Dog123”). Dog123 is a 32-bit pointer to a double object. Is Dog123 on heap or on stack or in global area?
If dog123 is not in heap, the delete will crash (UndefinedBehavior) — deleting a pointer to stack (or global)
if dog123 is in heap, then how is it allocated? (Now it’s best to draw memory layout.) I feel it is almost always a field in a class/struct. Supposed the 32-bit object dog123 is also referred to as student1.pointerToFee, like
double * pointerToFee;
// in this case, our smart pointer is perhaps set up like smart_ptr sptr( &(student1.pointerToFee) )
Now, if our “delete ptr2ptr2dbl” works, then the memory location occupied by Dog123 is reclaimed.
– that means the 64-bit double object is never reclaimed — memory leak
– also, student1.pointerToFee is in trouble. It’s not a wild pointer (its 64-bit pointee is ok), but the 32-bit memory location holding pointerToFee is reclaimed. On the real estate of student1instance, there’s now a 32-bit hole — 4 bytes de-allocated.
Q: how can we safely use this kind of smart pointer?
%%A: I guess we must use a custom deleter
Q: When would you need this kind of smart poitner?
%%A: I don’t think we need it at all.