overriding default copy-by-value semantics across a hierarchy of classes
Suppose I have two simple structs like A and B below ...
struct A {
// ...
public:
A() { /* ... */ };
A(const A&) { /* ... */ };
A& operator=(const A&) { /* ... */ };
};
struct B {
// ...
public:
B() { /* ... */ };
B(const B&) { /* ... */ };
B& operator=(const B&) { /* ... */ };
};
.... and I want to define a single base/derived hierarchy of classes
where the base, MyBase, maintains a private pointer to an instance of
A allocated on the heap, while MyDerived similarly maintains a
private pointer to a dynamically allocated instance of B. In each
case the private pointer-to-struct is initialized in the class
constructor and deleted in the destructor so, the next thing, then,
would be to provide an appropriate copy constructor and assignment
operator. So, for MyBase I would do something like this:
class MyBase {
A *a_ptr;
public:
MyBase(): a_ptr(new A) { }
MyBase(const MyBase& mb)
: a_ptr(new A(*mb.a_ptr)) { }
MyBase& operator=(const MyBase& mb) {
if (this != &mb) {
delete a_ptr;
a_ptr = new A(*mb.a_ptr);
}
return *this;
}
virtual ~MyBase() { delete a_ptr; }
};
I'm thinking this is plausible so far (?), and so for MyDerived
likewise I will need:
class MyDerived : public MyBase {
B *b_ptr;
public:
MyDerived(): b_ptr(new B) { }
MyDerived(const MyDerived&);
MyDerived& operator=(const MyDerived&);
~MyDerived() { delete b_ptr; }
};
Now all that is needed is to define the copy constructor and
assignment operator for MyDerived, and I'm wondering whether
the following would be the best way to do this:
MyDerived::MyDerived(const MyDerived& md)
: MyBase(md), b_ptr(new B(*md.b_ptr))
{ }
MyDerived& MyDerived::operator=(const MyDerived& md) {
if (this != &md) {
MyBase::operator=(md);
delete b_ptr;
b_ptr = new B(*md.b_ptr);
}
return *this;
}
Adding debug print statements suggests that these work as I would
want them to, but somehow the assignment operator in particular
looks a little clunky in needing to use the explicit function call
syntax for the base operator=. Are there perhaps other ways that
I have missed to define these last two functions that might be
better, even assuming that the general strategy is correct in the
first place?
(Please note that the overall 'design' of the hierarchy itself is
deliberately contrived merely as a learning exercise.)
Regards
Paul Bibbings
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]