Archived

This topic is now archived and is closed to further replies.

virtual copy constructor?

This topic is 5427 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

I would like to know how to make a copy constructor inheritable, and perhaps the operator= function as well. For instance...
// IComparable interface

class IComparable
{
public:
IComparable( const IComparable& obj );

// ...

virtual void operator=( const IComparable& obj );

virtual int lessThan( const IComparable& obj ) const;
};

// a class that derives from IComparable

class Person: public IComparable
{
public:
Person( const Person& p ): height(p.height)
{}

void operator=( const Person& p )
{
this->height = p.height;
}

int lessThan( const Person& p ) const
{
if (this->height < p.height)
return 1;
else
return 0;
}

private:
int height;
};

// now to the problem, I want to copy this IComparable object

// in part of a function

void f( IComparable obj )
{
IComparable newObject(obj);

// or similarly

IComparable newObject = obj;
}

Problem is, what if I pass in a Person to the f() function? What will operator= do? What will the copy constructor do? I''m having trouble wrapping my head around this.

Share on other sites
I'm thinking you might get an error on type mismatch, I'm not sure. Error might be something like, function f expects IComparable but got Person

Perhaps this might work. Have your f() accept a pointer to your base class IComparable. Then inside f() you can do dynamic_cast on your obj. This way you can tell whether your obj is just a base IComparable or it's a derived Person since dynamic_cast will return null if you try to cast obj that's a IComparable to a Person.

ok, here's some code to go with what I mean:
void f(IComparable *obj){    if(dynamic_cast<Person *>(obj)==null)    {        IComparable *newObject=new IComparable;        *newObject=*obj;    }    else    {        Person *newObject=new Person;        *newObject=dynamic_cast<Person>(*obj);    }}

hmm does that look right? I'm not sure hehe

ok, another edit. I think your virtual functions all need to have the same sig here. So in your Person Class, the copy and the assignment would both need to take IComparable as parameters, so this probably means overloading them; one for Person as parameter and one as IComparable for parameter. So now your Person class will know what to do when you try to intialize it with a IComparable object.

--{You fight like a dairy farmer!}

[edited by - Greatwolf on August 9, 2003 3:01:33 AM]

Share on other sites
AFAIK, constructors can''t be virtual. The only storage class attribute allowed for ctors is inline. I''m not sure about this, but I think the same may go for operator=.

Share on other sites
Okey, there are two problems here:

1) Constructors are not inheritable
2) The copy operator ( = ) is not inheritable

... Though, you could (i suppose) add a virtual clone function. For instance:
class IComparable {public:  // ...  virtual IComparable *clone() = 0;};class Person : public IComparable {public:  // ...  IComparable *clone() {    return new Person( *this );  }};void f( IComparable &obj ) {  IComparable *copy = obj.clone();}

I havn't tried it myself, so it might be all wrong, but it's an idea!

[edited by - genne on August 9, 2003 1:04:26 PM]

Share on other sites
Clone is the typical implementation, you can use co-variant return types too:

struct Base   {   virtual Base* Clone()=0;   };struct Derived : Base   {   virtual Derived* Clone()      {      return new Derived(*this);      }   };

Share on other sites
Yeah, clone is nice. You can do some nice things if all your classes have clone-func. and they all have the same baseclass (like cObject or what you would call it). Then you can keep a pool with an object for every class, letting dll-s or whatever add objects dynamicly to it, and then you can write a cObject::New-func, fakingly looking up classes runtime, returning a cloned object. This can be neat, but I''m sure not everyone would agree... maybe this was a bit of the thread, and not very clear, but it is worth mentioning anyway

• 34
• 12
• 10
• 9
• 9
• Forum Statistics

• Total Topics
631354
• Total Posts
2999498
×