UNIX Socket FAQ

A forum for questions and answers about network programming on Linux and all other Unix-like systems

You are not logged in.

#1 2005-08-29 04:43 PM

lenna
Member
Registered: 2004-08-21
Posts: 77

Re: stl::list

I have a function that receive an stl::list that holds a list of objects of class X. in this function I create objects of class X and add them to the list. of course the created objects X are local variables and destroyed at the end of the function.

If I'm correct then by adding an object X to the list I don't call copy cto'r to the list, and actually add the object itself to the list. I thought that might be problematic if the object will be destroyed at the end of the function (memory leak?).

Q1) am I correct?
Q2) how do you suggest to solve this problem? I thought of allocating the objects dynamically in the function using 'new', and that way to ensure that they will not be destroyed in the end of the function. is this a good solution?
Q3) if so, do I need to delete these dynamically allocated objects at any time or will the memory set free automatically by the OS when the stl::list will be destroyed?

thanks a lot,
Lenna

Offline

#2 2005-08-29 05:26 PM

i3839
Oddministrator
From: Amsterdam
Registered: 2003-06-07
Posts: 2,239

Re: stl::list

A1) Depends. If you let the list store objects of type X instead of pointers to X, then copies will be made. But if that list template uses references then no copies are made.

A2) This is the way to go yes. Much better than making copies too.

A3) In C++ you need to handle memory yourself, also the cleanup. So yes, destroying them when you don't need them anymore is a good idea. Memory is only claimed back by the OS when the program exits.

Offline

#3 2005-08-29 08:15 PM

lenna
Member
Registered: 2004-08-21
Posts: 77

Re: stl::list

Offline

#4 2005-08-29 09:17 PM

i3839
Oddministrator
From: Amsterdam
Registered: 2003-06-07
Posts: 2,239

Re: stl::list

If you have a class with consist only of one type of data then it shouldn't be a class at all, use that data directly instead.

I don't understand your other question. If you make a list subclass then yes you can make a destructor for it which frees all elements before disappearing. If you delete the list then the destructors of the elements in it aren't called, but you'll leak memory.

If the above doesn't answer your questions then clarify what you want to know.

Offline

#5 2005-08-30 10:37 AM

lenna
Member
Registered: 2004-08-21
Posts: 77

Re: stl::list

class X
{
   int a;
   char b[100];
}

Offline

#6 2005-08-30 02:23 PM

i3839
Oddministrator
From: Amsterdam
Registered: 2003-06-07
Posts: 2,239

Re: stl::list

A1) You can do that by wrapping the std:list in your own small class, either by inheritance or by cleaning up the list elements in the dtor of the enveloping class.

A2) To destroy an object call delete on it, the counterpart of new.

A3) Yes, correct.

Offline

#7 2005-09-07 01:07 PM

lenna
Member
Registered: 2004-08-21
Posts: 77

Re: stl::list

given the class X and the following list:

class X
{

               char a[100];
               int b;
}

list<X> XList;

X x1("a", 1);
X x2("b", 2);
X x1("c", 3);

XList.push_Back(x1);
XList.push_Back(x2);
XList.push_Back(x3);

which of the following options is the correct one if I want to delete a node and avoid memory leak?

option 1:

list<X>::iterator iter = XList.begin();
for(;iter != XList.end();)
{
             XList.pop_front();
}


option 2:

list<X>::iterator iter = XList.begin();
for(;iter != XList.end();)
{
             X* tmp = &(XList.front());
             XList.pop_front();
             delete tmp;
}



option 3:

list<X>::iterator iter = XList.begin();
XList.erase(iter)


which functions indicate amount of free memory so I can be sure there's no memory leak?

Offline

#8 2005-09-07 04:26 PM

i3839
Oddministrator
From: Amsterdam
Registered: 2003-06-07
Posts: 2,239

Re: stl::list

x1, x2 and x3 (typo there btw) are on the stack and will disappear when the function they're in returns. So you don't need to free their memory, that is done automatically. You should only need to care about memory you allocated yourself, by using new or malloc or anything that returns newly allocated data.

Assuming that you had dynamically allocated the X objects instead, something like:

X* x1 = new X("a", 1);

then option 1 makes no sense as popping something doesn't destroy the data (it's returned after all, so must be usable), and as you're going to delete the list anyway, doing all that work is also for nothing. Option 2 looks ok, although pop should return the object so the call to front is redundant. Option 3 just removes an element from the list by an index, thus just like 1 and 2 doesn't free any data.

To repeat: the data in your example is on the stack, so you don't have to free it.

Offline

#9 2006-03-15 09:45 PM

mlampkin
Administrator
From: Sol 3
Registered: 2002-06-12
Posts: 911
Website

Re: stl::list

Another old message that I just read... it appears to have been posted while I was off the forums ( which seems to be more often than not these day )...

The stl containers do take references for inserts, removes and so forth... and "call" the copy constructor to make a "duplicate" of the object to store...

So there may be worries about efficiency... why would you want to create a local object in a function... pass it to say a list... have the list make a copy... and then you exit the function and your original copy goes out of scope?  Sounds like a waste of time... but the truth is quite different... in such cases with even minimal optimization turned on the compiler should recognize that it really doesn't need to make a copy and no cycles are wasted...

If you are really worried about it then allocating on the heap and using pointers is fine except for one thing... quite often their use leads to very hard to track down memory leaks... so its probably best to use a std::auto_ptr or something similar to wrap your memory pointer when storing it... that way when it is pulled from the container and assigned / copied to a variable... when that variable goes out of scope the auto_ptr will take care of cleaning things up...

Of course for an auto_ptr etc. to work the object still has to clean up its own internal resource in its destructor ;-)


Michael


"The only difference between me and a madman is that I'm not mad."

Salvador Dali (1904-1989)

Offline

Board footer

Powered by FluxBB