Cloning

[pauldepstein]

Suppose class B is derived from class A As a public member function
in class B, there is a clone

A* clone() const {return new B(*this);}
When and why would this be preferred to B* clone() const{return new
B(*this);}

Thank you,

Paul Epstein

[Rolf Magnus]

pa**********@att.net wrote:

Suppose class B is derived from class A As a public member function
in class B, there is a clone

A* clone() const {return new B(*this);}
When and why would this be preferred to B* clone() const{return new
B(*this);}

I don't see a reason. I would choose the latter version.
Well, one reason I could imagine is that the author might not have known
about covariant return types.

[pauldepstein]

On Jul 7, 12:49*pm, Rolf Magnus <[e-mail]:

[e-mail] wrote:

Suppose class B is derived from class A * *As a public member function
in class B, there is a clone

A* clone() const {return new B(*this);}

When and why would this be preferred to B* clone() const{return new
B(*this);}

I don't see a reason. I would choose the latter version.
Well, one reason I could imagine is that the author might not have known
about covariant return types.

I don't know what covariant return types mean, either. I will google
them immediately. Feel free to include further comments, though.

Paul Epstein

[James Kanze]

On Jul 7, 4:03 am, [e-mail] wrote:

Suppose class B is derived from class A As a public member
function in class B, there is a clone

A* clone() const {return new B(*this);}

When and why would this be preferred to B* clone()
const{return new B(*this);}

Almost anytime the base class function returns an A*. (The C++
language supports co-variant return types, so returning a B*
here, even if the base class returns an A*, is legal. Normally,
however, it's not very useful, and only leads to confusion; I'd
avoid it except in exceptional cases.)

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Andrey Tarasevich]

pa**********@att.net wrote:

Suppose class B is derived from class A As a public member function
in class B, there is a clone

A* clone() const {return new B(*this);}
When and why would this be preferred to B* clone() const{return new
B(*this);}

Well, always. It is always better to specify the return type that
describes the actual type of the object being returned as closely as
possible.

With an issue as generic as this one, there are so many examples when
this might come useful that it is hard to choose just one.

Imagine, for example, that somewhere in your code you'd have to work
with the polymorphic class hierarchy rooted at 'B', possibly with some
specific interface features that originate in 'B' (but not present in
'A'). The code does not care, does not know, and does not need to know
about the rest of the hierarchy. With regard to the above 'clone'
function this is immediately and naturally achievable when the return
type is declared as 'B*'. Without it you'd have to use an explicit cast
to forcefully convert the return value to 'B*' type.

Also, you might need to call 'B::clone' is a completely non-polymorphic
context (like "I know a have a 'B' and I know I will get a 'B' from the
clone function"), where the return type of 'A*' looks simply ridiculous
and requires workarounds to make it work.

--
Best regards,
Andrey Tarasevich

[pauldepstein]

On Jul 8, 6:40*am, Andrey Tarasevich <[e-mail]>
wrote:

[e-mail] wrote:

Suppose class B is derived from class A * *As a public member function
in class B, there is a clone

A* clone() const {return new B(*this);}

When and why would this be preferred to B* clone() const{return new
B(*this);}

Well, always. It is always better to specify the return type that
describes the actual type of the object being returned as closely as
possible.

With an issue as generic as this one, there are so many examples when
this might come useful that it is hard to choose just one.

Imagine, for example, that somewhere in your code you'd have to work
with the polymorphic class hierarchy rooted at 'B', possibly with some
specific interface features that originate in 'B' (but not present in
'A'). The code does not care, does not know, and does not need to know
about the rest of the hierarchy. With regard to the above 'clone'
function this is immediately and naturally achievable when the return
type is declared as 'B*'. Without it you'd have to use an explicit cast
to forcefully convert the return value to 'B*' type.

Also, you might need to call 'B::clone' is a completely non-polymorphic
context (like "I know a have a 'B' and I know I will get a 'B' from the
clone function"), where the return type of 'A*' looks simply ridiculous
and requires workarounds to make it work.

--
Best regards,
Andrey Tarasevich

Thanks. However, just to clarify, I don't think you meant "Well,
always", but rather "Well, never."
After starting this thread, I read (from 2004), in reference to

B* clone() const{return new B(*this);}

"Many compilers will not compile this syntax, as this is an exception
to the general rule that you cannot override the return type of a
virtual function."

Paul Epstein