delete

N

Nethali

Hi all,

Please explain me the following:

I have struct as follows:

struct Link
{
void* data;
Link* next;
}

And I do following:
Link* newLink = new Link;
newLink->data = new string("aaaaaaaaaaaa");
newLink->next = 0;

My problem is this:
Above, I have allocated 2 memory areas, one for newLink and one for
string of "aaaaaaaaaaaa".
If I delete newLink ( ie: delete newLink; ) it will release the memory
area for newLink. Will it release the memory area allocated for
"aaaaaaaaaaaa" also? If so how it happens? If it is not so, how can I
relase memory area allocated for "aaaaaaaaaaaa"?

Thanks in advance.
 
J

John Harrison

Nethali said:
Hi all,

Please explain me the following:

I have struct as follows:

struct Link
{
void* data;
Link* next;
}

And I do following:
Link* newLink = new Link;
newLink->data = new string("aaaaaaaaaaaa");
newLink->next = 0;

My problem is this:
Above, I have allocated 2 memory areas, one for newLink and one for
string of "aaaaaaaaaaaa".
If I delete newLink ( ie: delete newLink; ) it will release the memory
area for newLink. Will it release the memory area allocated for
"aaaaaaaaaaaa" also?

No

If so how it happens? If it is not so, how can I
relase memory area allocated for "aaaaaaaaaaaa"?

Do it yourself. What will make this difficult in this case is that you
have chosen to make data a void* for some reason.

I'm not speculating any further until I've seen more code.
Thanks in advance.

john
 
S

Senthil

Hi all,

Please explain me the following:

I have struct as follows:

struct Link
{
void* data;
Link* next;

}

And I do following:
Link* newLink = new Link;
newLink->data = new string("aaaaaaaaaaaa");
newLink->next = 0;

My problem is this:
Above, I have allocated 2 memory areas, one for newLink and one for
string of "aaaaaaaaaaaa".
If I delete newLink ( ie: delete newLink; ) it will release the memory
area for newLink.

Yes,delete newLink would release the memory area for newLink object.

Will it release the memory area allocated for
"aaaaaaaaaaaa" also? If so how it happens? If it is not so, how can I
relase memory area allocated for "aaaaaaaaaaaa"?

No it does not release the memory for the string that you allocated
using new, it has to be deleted explicitly.
so your clean up code should be something like

delete static_cast<string*>(newLink->data);
delete newLink;

If you are wondering why the static cast id for, delete cannot be
aplied to a void*, simple reason being the compiler does not know
1. Which destructor to call(since the type is void)
2. The amount of memory to be freed.
Thanks in advance.

Best Regards,
Senthil
 
N

Nethali

No

If so how it happens? If it is not so, how can I


Do it yourself. What will make this difficult in this case is that you
have chosen to make data a void* for some reason.

I'm not speculating any further until I've seen more code.




john

Thanks john. I got your point. For others reference it is possible as
follows:

struct Link
{
void* data;
Link* next;
}

Link* newLink = new Link;
newLink->data = new string("aaaaaaaaaaaa");
newLink->next = 0;

void* temp = newLink->data;
delete newLink;
delete temp;
 
N

Nethali

Thanks john. I got your point. For others reference it is possible as
follows:

struct Link
{
void* data;
Link* next;

}

Link* newLink = new Link;
newLink->data = new string("aaaaaaaaaaaa");
newLink->next = 0;

void* temp = newLink->data;
delete newLink;
delete temp;

Sorry my previous code is wrong. You have to cast temp to some known
type. Code shown above by Senthil is right. Thanks Senthil.
 
?

=?ISO-8859-1?Q?Erik_Wikstr=F6m?=

Yes,delete newLink would release the memory area for newLink object.

Will it release the memory area allocated for

No it does not release the memory for the string that you allocated
using new, it has to be deleted explicitly.
so your clean up code should be something like

delete static_cast<string*>(newLink->data);
delete newLink;

You can make it automatic by using a destructor:

struct Link {
void* data;
Link* next;
~Link();
};

Link::~Link() {
delete static_cast<string*>(this->data);
}

Now the data will automatically be freed when the Link is. Of course if
you're always gonna store strings make data a string* from the start,
then you don't have to cast and the code will be better.
 
J

James Kanze

You can make it automatic by using a destructor:
struct Link {
void* data;
Link* next;
~Link();
};
Link::~Link() {
delete static_cast<string*>(this->data);
}
Now the data will automatically be freed when the Link is. Of
course if you're always gonna store strings make data a
string* from the start, then you don't have to cast and the
code will be better.

I think the key to the problem is there. If Link knows it will
be storing strings, then:

struct Link
{
std::string data ;
Link* next ;
} ;

is by far the best solution. And if Link doesn't know the type
of it's data, it can't delete it.

In C++, there are really only two acceptable solutions. If all
of the links have the same type of data:

template< typename T >
struct Link
{
T data ;
Link* next ;
} ;

Otherwise, something like:

struct AbstractData
{
virtual ~AbstractData() {}
} ;

template< typename T >
struct Data : public AbstractData
{
T value ;
} ;

struct Link
{
AbstractData* data ;
Link* next ;
explicit Link( AbstractData* init = NULL )
: data( init )
, next( NULL )
{
}
~Link() { delete data ; }
} ;

(I would not provide the destructor without also providing a
constructor to ensure that it could be called without undefined
behavior.)

Or use something existing, like boost::any, which more or less
wraps the data, takes care of all of the bookkeeping for you,
and provides a lot of support functions. (Somewhere deep inside
of boost::any, I'll bet you'll find something like the
AbstractData/Data pair above.)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,772
Messages
2,569,593
Members
45,111
Latest member
KetoBurn
Top