🔒 Locked

virtual copy constructor?

Started by Malone1234 Aug 9, 2003 at 1:08 AM 4 replies 3.9k views

Original Post

Aug 9, 2003 at 1:08 AM

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.

Greatwolf

Aug 9, 2003 at 1:34 AM

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]

sbennett

Aug 9, 2003 at 11:59 AM

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=.

genne

Aug 9, 2003 at 12:02 PM

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]

Shannon Barber

Aug 9, 2003 at 12:11 PM

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);
      }
   };

Jolle

Aug 9, 2003 at 12:21 PM

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

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.