On Thu, 23 Sep 2010 08:03:39 +0100 Robert Pearce <[email protected]> wrote: [snip] > That said, it may be as simple as the application does enough extra > work that it overwrites the freed up stack space in which your > "Object" instances were created. When you create "o" you do so on the > stack. You then "push_back" onto the std::vector. This does create a > copy, but you have not defined a copy-constructor for your "Object" > class, so that copy operation is uncontrolled. It will be a raw > binary copy, and will not invoke the ustring copy-constructor. > > It may be enough to overload your existing Object(int, char*) with a > version that takes a ustring, but it's better to explicitly define > > Object::Object ( Object o ) > { > id = o.id; > name = o.name; > }
The default (compiler provided) copy constructor will do exactly that, assuming the OP hasn't provided his own different copy constructor. In c++, the copying of objects of class type is not by raw binary copying. By default, each member object will have its own copy constructor operator called, if it has one, and if not it will have its default compiler provided copy constructor called. The same applies to assignment and the default assignment operators. That is not to say that the problem is not with the copy constructor or assignment operator, say if the OP has member objects allocated on the heap and held by pointer which are then double deleted by the destructors of the assignor and assignee (a common error). But the problem is not that a raw binary copy is made. Chris _______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
