Re: Initialising classes with pointers to this
On Apr 8, 5:22 pm, "Christopher Pisz" <some...@somewhere.net> wrote:
"Marcel M=FCller" <news.5.ma...@spamgourmet.com> wrote in message
news:47f9d24b$0$627$9b4e6d93@newsspool1.arcor-online.net...
Christopher Pisz schrieb:
Not really. A Clone method is most likely some programmer's obsession
with Java coming out in their C++ code. There is really no sense having=
a
clone method in C++. We overload operator = or provide a copy
constructor.
I do not agree to the last statement. In polymorphic classes there may b=
e
a need to invoke the copy constructor in abstact base classes. And since=
the C++ language does not provide a direct way to do this (most other OO=
languages too), a virtual clone method is a common work-around.
Marcel
Yea, I've seen that too. I think its a bunch of ick. Requiring the Abstrac=
t
class to know the definition of a derived classes, creating a circular
dependancy. I've also seen people implementing a derived class code
identifier in all the classes in order for the abstract class to tell "wha=
t
kind am I cloning". There are better solutions IMO.
Why must the abstract base class know the definition of a derived
class? Because the C++ standard allows for covariant return types, the
base class can be made completely oblivious to what subclasses are
defined (that's the whole point). For example:
class Base
{
public:
// Constructor and other functions omitted for clarity
virtual Base* clone() const = 0;
};
class Derived : public Base
{
public:
// Constructor and other functions omitted for clarity
virtual Derived* clone() const;
};
Note that the return type for the clone() function in Derived is
Derived*, not Base* as declared in the base class. I'm struggling to
see why the base class would need to know what type it is cloning.
Perhaps you could post an example?
--
Computational Modeling, CSIRO (CMIS)
Melbourne, Australia