is std::list<obj>.push_back suppose to do a deep copy?

[SpreadTooThin]

if I build a list of objects does push_back end up making a copy of
the object itself?

I have a problem.. when the list is destroyed...
as an example of what my code does....

std::list<myObject> myListOfObjects;
myObject obj;

for i=0; i < n; ++i
{
obj.modifySomeProperty;
myList.push_back(obj);
}

When the function returns the list is destroyed by going out of
scope.. and of course so is obj.
First off ... Maybe I should have created a new instance of myObject
on each iteration of the loop or perhaps using the same one over and
over again is OK.... (as long as push_back is making a copy of the
object.)

Suggestions?

 

[mzdude]

if I build a list of objects does push_back end up making a copy of
the object itself?

I have a problem.. when the list is destroyed...
as an example of what my code does.... What is the problem?

std::list<myObject> myListOfObjects;
myObject obj;

for i=0; i < n; ++i
{
   obj.modifySomeProperty;
   myList.push_back(obj);

}

When the function returns the list is destroyed by going out of
scope.. and of course so is obj. What function?
First off ... Maybe I should have created a new instance of myObject
on each iteration of the loop or perhaps using the same one over and
over again is OK.... (as long as push_back is making a copy of the
object.)

Suggestions?

Yes. Ask what you want to know?

void MyFunc()
{
std::list<MyObject> myList;
MyObject myObject;
for(int i=0; i < 10; ++i) {
myObject.modify();
myList.push_back(myObject); // Makes a copy
}

// do some stuff with my list

} // dtor of myObject, myList (an all objects in myList)


If the question is how many MyObjects exist at the end of the
function,
the answer would be 11. The one on the stack and the 10 in the list.
And yes all 11 dtors would be called.

If the question is, are there memory leaks? Insufficient info. Need to
know much more about MyObject. What does it contain? Does it need a
copy constructor? Is one defined?

 

[SpreadTooThin]

What is the problem?






Yes. Ask what you want to know?

void MyFunc()
{
   std::list<MyObject>  myList;
   MyObject myObject;
   for(int i=0; i < 10; ++i) {
      myObject.modify();
      myList.push_back(myObject);   // Makes a copy
   }

   // do some stuff with my list

} // dtor of myObject, myList (an all objects in myList)

If the question is how many MyObjects exist at the end of the
function,
the answer would be 11. The one on the stack and the 10 in the list.
And yes all 11 dtors would be called.

That is helpful.

If the question is, are there memory leaks? Insufficient info. Need to
know much more about MyObject. What does it contain? Does it need a
copy constructor? Is one defined?

The class defines operator=, a copy constructor and a destructor.

but the program crashes during the destruction of the second object..
wierd...

 

[red floyd]

That is helpful.


The class defines operator=, a copy constructor and a destructor.

but the program crashes during the destruction of the second object..
wierd...

Are you shallow-copying dynamically allocated pointers?

e.g (minimal example):

class X {
T *p;
public:
X(const X& x) p(x.p) { }
X& operator=(const X& x)
{ p = x.p; }
~X() { delete p; }
};

 

[mzdude]

Are you shallow-copying dynamically allocated pointers?

e.g (minimal example):

class X {
   T *p;
public:
   X(const X& x) p(x.p) { }
   X& operator=(const X& x)
       { p = x.p; }
   ~X() { delete p; }

};

You can remove the list as part of the problem.

void MyFunct()
{
MyObject myObj1;
MyObject myObj2(myObj1);
MyObject myObj3;
myObj3.modify();
myObj1 = myObj3;
}

My guess is the above function will display
the same issues as your list problem. And it should
be much easier to track down.

 

[Jerry Coffin]

(e-mail address removed)>, (e-mail address removed)
says...

if I build a list of objects does push_back end up making a copy of
the object itself?

Yes -- it copies the item into the data structure using whatever copy
constructor is defined for the type of the item.

 

[SpreadTooThin]

You can remove the list as part of the problem.

void MyFunct()
{
  MyObject  myObj1;
  MyObject  myObj2(myObj1);
  MyObject  myObj3;
  myObj3.modify();
  myObj1 = myObj3;

}

My guess is the above function will display
the same issues as your list problem. And it should
be much easier to track down.

Thanks for the help. I think there is pointer screw up somewhere in
the code that is causing this odd symptom for me.

 

[SpreadTooThin]

Are you shallow-copying dynamically allocated pointers?

e.g (minimal example):

class X {
   T *p;
public:
   X(const X& x) p(x.p) { }
   X& operator=(const X& x)
       { p = x.p; }
   ~X() { delete p; }

};

Nope deep copies with memcpy on all data that is held by a pointer.

 

[Bart van Ingen Schenau]

Nope deep copies with memcpy on all data that is held by a pointer.

The memcpy could be part of the problem. memcpy can only be safely used
to copy POD objects (in short: objects that are also acceptable to a C
compiler).

Bart v Ingen Schenau

 

[SpreadTooThin]

I assume this means you saw the problem with his list-less code?  You
should now remove bits of the MyObject class until it stops failing -
and look _very_ closely at the last bit you took out before the failure
went away.

Andy

One piece of code was behaving in two separate ways depending on it
was being used.
In one case where it was tried and true it wasn't in a thread. In the
case where it was failing it was in a thread.
Changing a variable to a static from auto fixed the issue. Perhaps
this object was not constructing properly on the stack or due to it
being in a thread...

Its a simple class that is declared:

myClass : public std::list<myObject>
{
.... stuff.
};

I narrowed it down to the instantiation as if I tried to get the
objects size immediatly after instantiation caused the application to
die...

so:

MyClass a;
a.size(); //BOOOM!

static MyClass a;
a.size(); //0 OK!

So I'm not confident of this fix.. but its the only thing I know about
why its failing.

To top it off the debugging environment is just about power less in
this environment as I am debugging the c++ class from inside a Basic
application that uses the class as a 'plugin'....