Printable View
I've been reading and understand that classes that contain dynamically allocated members will copy only the pointer to these members when using the default constructors. But I've only seen this in the context of using "new", "malloc", etc...
Are the STL containers immune to this? Or do I still need to provide my own copy and/or assignment constructor?
The default copy constructor basically invokes the copy constructor of each member, unless it's a built-in type (int, double, pointers, etc), in which case the underlying bytes are simply copied into the member. In the case of pointers that are "managed" by the object this can be disastrous, as multiple objects are then prone to "free" the object.Quote:
Originally Posted by micahharwell
So...yes, you generally need to write your own copy constructor in such a case (or else use a "smart-pointer", or similar).Code:#include <iostream>
struct foo
{
foo( void )
{
data = new int;
}
~foo( void )
{
std::cout << "foo (" << static_cast< void* >( this ) << ") freeing data (" << data << ")" << std::endl;
delete data;
}
int* data;
};
int main( void )
{
foo a, b = a;
}
If you build your data types only from other data types that do the right thing when copied, then you'll never need to write a copy constructor or assignment operator ever.
You are always responsible for making sure that your classes have well-defined copy and assignment behaviour. The only other acceptable option is to prevent use of those things through the standard "private & unimplemented" technique.
Alrighty! Thanks guys! It's a learning curve, but I'm climbing it - and this board gives me a foothold when I can't find one.
Smart pointers can help you avoid having to write logic for copying these members.
And STL containers are designed so that they are safe to copy. You don't need to worry about those.
.... assuming the objects they contain are safe to copy.Quote:
Originally Posted by Elysia
If an object type does not have a safe copy constructor (eg it contains a pointer to a resource, and no copy constructor and assignment operator to properly copy that resource) putting it in a STL container produces a container that cannot be safely copied either.
Okay. In my application, the only dynamic members are STL containers. It appears that they are "copy safe". Thanks again guys.
Erm. Good point.Quote:
Originally Posted by grumpy
It can be said that the STL libraries themselves are safe to copy, but their contents are not. The libraries will invoke the default copy constructor and/or assignment operator when copying them. Therefore, those must be safe for the type you're storing or you will not be able to safely copy containers.
All of that silliness can be avoided if you ensure that your fundamental types are safe to copy. Copy safety, and for that matter exception safety and resource safety, spring from the lowest level datatypes and percolate upward in the design.
If you find yourself writing a copy constructor, stop and ask yourself whether you really ought to be changing the lower-level data types to do the right thing instead. The number of low-level types is limited. The number of higher level types is potentially infinite. I prefer to do a finite amount of work, not an infinite amount of it.
If by "fundamental types" you mean the types that are building blocks of your application, I agree. (Sorry about being picky, but the term could mean many things).Quote:
Originally Posted by brewbuck
The only exception I would make is with those types that should not be copied (in which case I declare a private copy constructor and don't implement it). And, whatever I do with a copy constructor, I mirror with an assignment operator.