I thought I'd jot down some notes on what I do when designing new classes in C++ to be copyable. I'd be curious to get some feedback as I'm not sure what the C++ community at large does...
Anyway, when creating a new class where objects of that class need to be copyable, the first thing I ask myself is:
1. Is the new class a Plain Old Data type?
My definition of a Plain Old Data type ("POD") is one that simply includes a fixed amount of publicly accessible data. This rules out anything that would include a member function, anything that has any dynamic memory allocation aspects and anything that would have protected/private data members.
If so, designing the class can be quite simple. I don't need to worry about:
- copy constructors
- assignment operators
- destructors
class DatabaseRow {
public:
unsigned int Id;
unsigned short Year;
char FilmName[255];
DatabaseRow(unsigned int _id, unsigned short _year, const char* _filmName)
: Id(_id), Year(_year)
{
FilmName[0] = 0;
if(_filmName) {
if(strlen(_filmName) < 255) {
strcpy(FilmName, _filmName);
}
else {
memcpy((void*)FilmName, (void*)_filmName, sizeof(char) * 254);
FilmName[254]=0;
}
} // if(_filmName)
} // end constructor
};
The compiler will supply hidden default (no-argument) constructor and a copy constructor for the above class which will work fine (since all data members are fixed length, no dynamic memory allocation takes place). There is also no need for an explicit destructor since all data members are automatically destroyed.
2. If not a POD, will I really need to copy objects of this class?
Sometimes it's obvious when you will need to do copies, other times it's not so obvious but it becomes convenient. For instance, if I want to avoid having to allocate and (remember to) de-allocate memory at runtime for an object I sometimes want to make it part of a class. i.e.:
class C1 { ... }
class C2 {
C1 objectOfTypeC1;
};
In the above, I want C2 to contain an object of type C1 when C2 is instantiated. I don't want to have C2 contain a pointer to C1 and then have to allocate a C1 inside C2's constructor then remember to de-allocate a C1 when C2 is destroyed (lest I cause a memory leak). Any time I can avoid having to keep track of a pointer, I usually try to (though smart pointers can ease this task and static allocation really has become just a preference of mine).
Another scenario is when you have an array of objects:
class C3 {
C1 anArrayOfC1s[2085];
};
Now an object of type C3 contains an array of 2085 C1 objects which are allocated when the object of type C3 is instantiated.
One problem with doing the above is that the C1 objects are statically created when the enclosing class is created using a default (no-argument) constructor. Often-times objects of the contained class (C1) cannot be constructed meaningfully at the time of the enclosing class' (C2) instantiation, especially if it's during program startup as opposed to at run-time.
Ultimately, this means you cannot specify any details about the individual C1 objects and often need to "initialize" those objects at some later state (a messy approach) or "reconstruct" those objects and copy them back to data members of the enclosing class.
For scenarios like this, it means I will supply the following:
- A copy constructor
- An assignment operator
I usually throw in a default, no-argument constructor and a destructor at this point too. Here's my standard approach for this, which I've been using for a couple years now:
class DataBaseTable {
private:
string Name;
vector<DatabaseRow> Rows;
protected:
bool deepcopy(const DataBaseTable& rhs) {
bool bResult = false;
if(&rhs != this) {
this->Name = rhs.Name;
vector<DatabaseRow>::iterator it = rhs.Rows.begin();
while(it != rhs.Rows.end()) {
this->Rows.push_back(*it);
++it;
}
bResult = true;
}
return bResult;
}
public:
DataBaseTable() : { Name[0] = 0; }
DataBaseTable(const DataBaseTable& rhs) { deepcopy(rhs); }
DataBaseTable& operator=(const DataBaseTable& rhs) { deepcopy(rhs); return *this; }
const DatabaseRow& getRow() const { ... }
};
We supply a member function called "deepcopy" that ensures all data members are properly copied from "rhs" to "this" in a proper fashion.
The reason I return bool from this function is so that with a hierarchy of classes (all of which must be copyable), I can reuse the base class' deepcopy as a starting point. For example:
class Base {
private:
int arrayLength;
int* someArray;
protected:
bool deepcopy(const Base& rhs) {
bool bResult = false;
if(&rhs != this) {
this->arrayLength = rhs.arrayLength;
this->someArray = new int[this->arrayLength];
for(int ind = 0; ind < this->arrayLength; ++ind) { this->someArray[ind] = rhs.someArray[ind]; }
bResult = true;
}
return bResult;
}
// etc...
};
Now in a derived class, deep copying can be extended like so:
class Derived : public Base {
public:
int someOtherValue;
protected:
bool deepcopy(const Derived& rhs) {
bool bResult = Base::deepcopy(rhs);
if(bResult) {
this->someOtherValue = rhs.someOtherValue;
}
return bResult;
}
// etc...
};
Of course the drawback of this technique is that every class in your hierarchy has to have a "deepcopy" method. However, it does save time when writing the assignment operator and copy constructors, since they rely on the deepcopy method and their function bodies become completely trivial.
3. Should copying an object cause any side effects to the original object?
This is a little trickier topic, since while the answer seems very obvious at first I've come across a scenario where it wasn't the case. My example was when an object had sole responsibility or control over an external resource and I needed to transfer ownership to the new copy and remove ownership from the old copy. This means that copying an object has a side effect to the copied object on the right-hand-side of the assignment operator.
In this case, you will have to remove the keyword "const" from the deepcopy, copy constructor and assignment operator methods. You should also explicitly document what is going on when a copy is made as a client/user will assume (and rightfully so) that performing a copy will leave the right-hand-side copy unscathed.
Ideally you should avoid these scenarios altogether by redesigning your code in such a way that the right-hand-side object is not affected by the copy (Note that smart pointers may have helped me avoid this scenario).