Deleting the object pointed by shared_ptr

[maalathi]

Hello everyone,

Am new to shared_ptr & vector concepts & learned the basics by google it.

But freeing the memory allocated which shared_ptr points to; is still not clear to me.
Below is the code snippet .. here i want to delete the memory allocated to 'baseobj '.

vector<shared_ptr<DerivedClass>> fun(){
vector< shared_ptr<DerivedClass> > vec;

<BaseClass> *baseobj = new <BaseClass>;
<DerivedClass> *derivObj = (derivedClass*) baseobj;

//! create shared_ptr
shared_ptr<DerivedClass> a(derivObj);

//! push it to vector
vec.push_back(a);
}

int main(){

vector<shared_ptr<DerivedClass>> dc = fun();
//! process the data in 'dc'

//! cleanup the memory - How to do ???

return 0;

}

Plz give your suggestions & ideas..
Thank u for ur precious time.

- Malathi

[jsmith]

shared_ptr already manages the memory for you.

In your example, all elements of "dc" will be destroyed when "dc" goes out of scope (since there are no other references to any of those shared_ptrs).

[simeonz]

Actually, I think that the OP's example results in undefined behavior, if not for anything else, because you can not delete base class object through pointer to derived class object. This may accidentally not glitch for technical reasons, but it is not portable at any rate. Second, deallocation is not the only concern. Performing downcast of pointer to base object to pointer to derived object, when in fact the pointed object is of type base, results in undefined behavior, even if you perform upcast before usage.

Regards

[jsmith]

Yes, you're right. I did not look closely at what was going on inside fun(). Now that I look again, fun() isn't even returning anything.

[maalathi]

Thanks jsmith and simeonz for ur suggestions.

jsmith,

ofcourse, it's true that "all elements of "dc" will be destroyed when "dc" goes out of scope"..
But when i run the appln as daemon, memory usage get's increased and was detected as memory leak in "Visual Leak Detector" tool.
-fun() will return 'vec'. missed out in the code.

simeaonz,

first am typecasting from base to derived object. then is it not possible to typecast the derived object to baseclass object & then delete it ?


Apart from base & derived class collapse, is it possible to delete the allocated object memory pointed by shared_ptr ? i think yes ( i will give a try at real time).. plz correct me if i am wrong.

Thanks
Maalathi

[simeonz]

I seriously looked at shared_ptr after your original inquiry, because I was unsure of some details. I thought its implementation targeted memory efficiency and was kind-of rigid, but it sacrifices memory efficiency for versatility.

The basic implementation of (reference counting garbage collecting) smart pointer keeps pointer to proxy object. In the proxy, it maintains the reference count and holds the value of the actual raw pointer. The proxy is dynamically allocated and is shared by (hopefully) all smart pointers that reference the same managed object.

The management policy concerns primarily the copy constructor, copy assignment operator, and destructor. When you create another copy of the smart pointer (with constructor or assignment), you increment the count inside the proxy. When you discard one of the copies (with destructor or overwriting with assignment), you decrement the reference count. And of course, the actual pointed object is destroyed using the raw pointer when the reference count reaches zero. After that the proxy is also destroyed.

With this strategy, you can not point to (different) sub-objects (base classes, fields, fields of fields, etc.), because all smart pointers that manage the same object share the count and the raw pointer. Second, the proxy indirection slows down the access a bit.

The alternative is to add another raw pointer as field stored directly in the smart pointer. It points to the sub-object (or more generally any controlling object) that is accessed with this smart pointer. The additional field is outside the proxy and is therefore not shared, which means that its value is independent, but it doubles the memory used for individual smart pointers.

To support weak pointers, the proxy maintains one additional reference count that impacts only the lifetime of the proxy itself. But this is not important.

What I am saying is this: you can point the smart pointer to virtually anything, and still manage the lifetime of one specific object that you wish. You can even point the smart pointers to static variables, and still manage some dynamically allocated memory through them. And you certainly can cast to your heart's content, as long as the casts are valid.

maalathi wrote:

then is it not possible to typecast the derived object to baseclass object & then delete it ?

No. It may work in practice with actual compilers, but the standard does not guarantee that performing invalid downcast and then reversing it with upcast recovers the original pointer. But it will probably work in practice if you test it.

Regards

[maalathi]

Thanks simeon for the detailed explantion. Gives some idea on shared & smart poniters.

Let me try.


Thanks
Maalathi