Cloning

Discussion in 'C++' started by pauldepstein@att.net, Jul 7, 2008.

  1. Guest

    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
    , Jul 7, 2008
    #1
    1. Advertising

  2. Rolf Magnus Guest

    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.
    Rolf Magnus, Jul 7, 2008
    #2
    1. Advertising

  3. Guest

    On Jul 7, 12:49 pm, Rolf Magnus <> wrote:
    > 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
    , Jul 7, 2008
    #3
  4. James Kanze Guest

    On Jul 7, 4:03 am, 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:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Jul 7, 2008
    #4
  5. 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
    Andrey Tarasevich, Jul 7, 2008
    #5
  6. Guest

    On Jul 8, 6:40 am, Andrey Tarasevich <>
    wrote:
    > 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
    , Jul 9, 2008
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Guest

    Cloning Possible?

    Guest, Nov 10, 2003, in forum: ASP .Net
    Replies:
    1
    Views:
    398
    Steve C. Orr [MVP, MCSD]
    Nov 11, 2003
  2. =?Utf-8?B?QVZM?=

    cloning

    =?Utf-8?B?QVZM?=, Dec 14, 2004, in forum: ASP .Net
    Replies:
    3
    Views:
    492
    Eliyahu Goldin
    Dec 14, 2004
  3. Joel Leong

    Cloning ASPNET account

    Joel Leong, Jun 4, 2005, in forum: ASP .Net
    Replies:
    1
    Views:
    351
    Scott Allen
    Jun 4, 2005
  4. Neven Klofutar

    Deep cloning

    Neven Klofutar, Jul 7, 2005, in forum: ASP .Net
    Replies:
    1
    Views:
    429
    =?Utf-8?B?bG9uZG9uIGNhbGxpbmc=?=
    Jul 7, 2005
  5. =?Utf-8?B?UCBL?=

    Datasets - Cloning problems

    =?Utf-8?B?UCBL?=, Mar 31, 2006, in forum: ASP .Net
    Replies:
    3
    Views:
    372
    sirfunusa
    Mar 31, 2006
Loading...

Share This Page