copy ctor question

[scooter]

Given this class heirarchy

class Base{};

class A : public Base
{};

class B : public Base
{};

etc

How do I go about coding a copy ctor for the following class:

class SomeClass
{
std::vector<Bas e*> m_BasePointers;
};

when m_BasePointers contains pointers to child classes of Base?


thanks

[Attila Feher]

scooter wrote:

Given this class heirarchy

class Base{};

class A : public Base
{};

class B : public Base
{};

etc

How do I go about coding a copy ctor for the following class:

class SomeClass
{
std::vector<Bas e*> m_BasePointers;
};

when m_BasePointers contains pointers to child classes of Base?

Do you want to copy what Base* points to? Well, that is not very simple...
I mean it is, but forcing it work isn't (you cannot force people to write
correct code).

// I hope you have meant:
class Base{
virtual ~Base();
};

// Now let's add a clone function:
class Base{
virtual ~Base();
virtual Base *Clone() const {
return new Base(*this);
}
};
class A : public Base
{
virtual A *Clone() const{
return new A(*this);
}
};

class B : public Base
{
virtual B *Clone() const{
return new B(*this);
}
};

The trouble with that is that if someone forgets to write his clone in a
derived class you get slicing. :-(

Now all you need to do is to use Base::Clone() to copy the elements.

Some please add testing using the RTTI into the base class(es) to check if
*this is actually a Base when the function is called. If not, they assert
(abort).

--
Attila aka WW

[Unforgiven]

scooter wrote:

Given this class heirarchy

class Base{};

class A : public Base
{};

class B : public Base
{};

etc

How do I go about coding a copy ctor for the following class:

class SomeClass
{
std::vector<Bas e*> m_BasePointers;
};

when m_BasePointers contains pointers to child classes of Base?

I'm assuming you want the Base-derived objects to be copied in the process?
Because if just copying the pointer values is what you want the copy
constructor of std::vector should already do the trick.

Your best option (IMHO) is probably to give Base a 'clone' function, that
you implement in A and B to create new (equivalent) As and Bs, and use that
in the copy constructor of SomeClass:

<code>
class Base
{
public:
virtual Base* Clone() const = 0;
};

class A : public Base
{
public:
A(A &a) { /*copy const for A*/ }
virtual Base* Clone() const
{
/* Caller must delete pointer! */
return new A(*this);
}
};

/* Same for B as for A */
</code>

Writing the copy constructor should be easy then.

--
Unforgiven

A: Top Posting!
Q: What is the most annoying thing on Usenet?

[Ralf Schneeweiß]

> class B : public Base

{
virtual B *Clone() const{
return new B(*this);
}
};

Well, your solution is the prototype pattern. A good idea can be the
implementation of the copy-constructor, because you are using it:
class B : public Base
{
public:
B( const B& b )
{
...
}

virtual B *Clone() const{
return new B(*this); // Here the copy-constructor is used.
}
};
Ralf
http://www.oop-trainer.de

[Ralf Schneeweiß]

The solution described by Attila Feher is the prototype pattern of the GoF.
The idea is to give a polymorphic (virtual) method, which can create a copy
of your polymorphic object. The problem is, that a constructor never can be
virtual.
You have to call it by its correct name, which ist the class name. Copying a
polymorphic object with the constructor would force you to find out the
object type
before you are copying. This is the reason for the virtual clone() method.
A good idea is to use the copy-constructor inside the clone() method.
Ralf

http://www.oop-trainer.de

[Attila Feher]

Ralf Schneeweiß wrote:

class B : public Base
{
virtual B *Clone() const{
return new B(*this);
}
};

Well, your solution is the prototype pattern. A good idea can be the
implementation of the copy-constructor, because you are using it:

And since the class contains absolutely no managed resources the copy
constructor syntetized by the compiler is just fine.

--
Attila aka WW

[Attila Feher]

Ralf Schneeweiß wrote:

The solution described by Attila Feher is the prototype pattern of
the GoF. The idea is to give a polymorphic (virtual) method, which
can create a copy of your polymorphic object.
It is very similar, but the motivation is completely different. Therefore
it looks like the Prototype pattern, but it isn't. One reason for that is
that it is not used to provide copies of prototypes.
The problem is, that a constructor never can be virtual.
Which does not matter for use, since we use polymorphic behavior, so we do
not work with constructors directly.
You have to call it by its correct name,
which ist the class name.
Which does not apply here, since we do not know the class name.
Copying a polymorphic object with the constructor would
force you to find out the object type before you are copying.
This is the reason for the virtual clone()
method. A good idea is to use the copy-constructor inside the clone()
method.

It *is* using the copy constructor.

--
Attila aka WW

[Howard]

"Attila Feher" <at**********@l mf.ericsson.se> wrote in message
news:bl******** **@newstree.wis e.edt.ericsson. se...

Ralf Schneeweiß wrote:

The solution described by Attila Feher is the prototype pattern of
the GoF. The idea is to give a polymorphic (virtual) method, which
can create a copy of your polymorphic object.
It is very similar, but the motivation is completely different. Therefore
it looks like the Prototype pattern, but it isn't. One reason for that is
that it is not used to provide copies of prototypes.

The problem is, that a constructor never can be virtual.

Which does not matter for use, since we use polymorphic behavior, so we do
not work with constructors directly.

You have to call it by its correct name,
which ist the class name.

Which does not apply here, since we do not know the class name.

Copying a polymorphic object with the constructor would
force you to find out the object type before you are copying.
This is the reason for the virtual clone()
method. A good idea is to use the copy-constructor inside the clone()
method.

It *is* using the copy constructor.

--
Attila aka WW

I think you're misunderstandin g Ralf's intention. If *I'm* understanding it
correctly, he's not disagreeing with you, but rather providing an
explanantion as to why yours is a good solution. At least, that's what I
got out of it. (The statement "the problem is..." isn't a complaint about
your solution, but an explanantion of the problem that *led* to the
solution.) Ralf, forgive me if I'm wrong, but that is what you meant, isn't
it?

(BTW, what's "GoF"???)

-Howard

[lilburne]

Attila Feher wrote:

Ralf Schneeweiß wrote:

class B : public Base
{
virtual B *Clone() const{
return new B(*this);
}
};

Well, your solution is the prototype pattern. A good idea can be the
implementatio n of the copy-constructor, because you are using it:

And since the class contains absolutely no managed resources the copy
constructor syntetized by the compiler is just fine.

Keep the copy ctor, because you'll probably end up adding
data to the class, and at sometime you'll have a debugging
session where you'll want to know when the damn thing is
copy conbstructed.

Kick out the inlines though, virtual inlines are definitely
a mistake, and the rest are a waste of time, and only serve
to clutter your headers with implementation details.

[WW]

lilburne wrote:

Well, your solution is the prototype pattern. A good idea can be the
implementation of the copy-constructor, because you are using it:

Again: it is not the Prototype pattern, it just happens to look like it.
The motivation of the Protoype pattern is completely different from the
motivation here. The things this code copies are not prototypes.
And since the class contains absolutely no managed resources the copy
constructor syntetized by the compiler is just fine.

Keep the copy ctor, because you'll probably end up adding
data to the class, and at sometime you'll have a debugging
session where you'll want to know when the damn thing is
copy conbstructed.

Big mistake. Huge mistake. Adding a copy constructor to a class having no
controlled resources is a mistake. It's copy constructor will be identical
to the one generated by the compiler - at best. However it introduces
maintenance risk and nightmare for no value.

If someone needs to know when a class is copied that person can look at the
language definition. Or make a small, 15 lines test program if unsure. BTW
copy constructors with side effects are rarely a good idea.
Kick out the inlines though, virtual inlines are definitely
a mistake, and the rest are a waste of time, and only serve
to clutter your headers with implementation details.

Have you looked at the language definition lately? I do not recall virtual
inlines being a mistake. And writing things inline in an untested example
code does not mean that they have to be written inline in real code
either...

BTW such a clone function is "final". So making it inline is not a mistake.
Although in this case adds not much, since such a function will only be
called via a pointer to (some) base. For this (by you unmentioned) reason
it makes sense not to make them inline. BTW I hope you did know that
virtual functions (if the dynamic type is known compile time) *can* be
inlined.

--
WW aka Attila