Re: segmentation fault when window closes

[Chris Vine <chris cvine freeserve co uk>]

On Thu, 23 Sep 2010 08:03:39 +0100
Robert Pearce <rob bdt-home demon co uk> 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