Derived::Derived(const Base&)

Discussion in 'C++' started by developereo@hotmail.com, May 22, 2007.

  1. Guest

    Hi folks,

    Can anybody shed some light on this problem?

    class Interface {
    public:
    Interface() { ...}
    virtual ~Interface() { ...}
    virtual method() = 0;
    };

    class Impl1: public Interface {
    public:
    Impl1() { ...}
    Impl1(const Interface&); // problem 1
    virtual ~Impl1() { ... }
    Impl1& operator=(const Interface&); // problem 2
    };

    The problem is that the compiler insists on generating the following
    methods:
    Impl1(const Impl1&); // copy constructor
    Impl1& operator=(const Impl1&); // assignment operator
    for me.
    I do not need these methods.
    I do not want these methods.
    I would have thought the compiler would call one of my explicit
    methods since every Impl1 is also an Interface.

    Is there some simple trick I am missing here?

    Thanks,
    J.
    , May 22, 2007
    #1
    1. Advertising

  2. * :
    > Hi folks,
    >
    > Can anybody shed some light on this problem?
    >
    > class Interface {
    > public:
    > Interface() { ...}
    > virtual ~Interface() { ...}
    > virtual method() = 0;
    > };
    >
    > class Impl1: public Interface {
    > public:
    > Impl1() { ...}
    > Impl1(const Interface&); // problem 1
    > virtual ~Impl1() { ... }
    > Impl1& operator=(const Interface&); // problem 2
    > };
    >
    > The problem is that the compiler insists on generating the following
    > methods:
    > Impl1(const Impl1&); // copy constructor
    > Impl1& operator=(const Impl1&); // assignment operator
    > for me.
    > I do not need these methods.
    > I do not want these methods.
    > I would have thought the compiler would call one of my explicit
    > methods since every Impl1 is also an Interface.


    No. Both the copy constructor and the copy assignment operator are very
    special member functions (thus, listend under "Special member
    functions"). They're generated if they're used and not declared.


    > Is there some simple trick I am missing here?


    At the technical C++ level: just declare them.

    But at the design level, having polymorphic assignment is almost never a
    good idea.

    Have you really thought through the consequences, how to handle all
    combinations of destination and source (e.g., run time errors)?


    --
    A: Because it messes up the order in which people normally read text.
    Q: Why is it such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
    Alf P. Steinbach, May 22, 2007
    #2
    1. Advertising

  3. <> wrote
    > Hi folks,
    >
    > Can anybody shed some light on this problem?
    >
    > class Interface {
    > public:
    > Interface() { ...}
    > virtual ~Interface() { ...}
    > virtual method() = 0;
    > };
    >
    > class Impl1: public Interface {
    > public:
    > Impl1() { ...}
    > Impl1(const Interface&); // problem 1
    > virtual ~Impl1() { ... }
    > Impl1& operator=(const Interface&); // problem 2
    > };
    >
    > The problem is that the compiler insists on generating the following
    > methods:
    > Impl1(const Impl1&); // copy constructor
    > Impl1& operator=(const Impl1&); // assignment operator
    > for me.
    > I do not need these methods.
    > I do not want these methods.
    > I would have thought the compiler would call one of my explicit
    > methods since every Impl1 is also an Interface.
    >
    > Is there some simple trick I am missing here?
    >


    The compiler needs the derived copy constructor for declaring and returning
    derived objects.
    The operator= however should follow the NVI (NonVirtual Interface) design
    pattern explained in:
    C++ Coding Standards, by Sutter and Alexandrescu,
    That is operator= should be non-virtual and only be declared in the base
    class, and simply call the virtual assign method, see item 55 in the book
    mentioned.
    As an application example of this and the NVI design pattern you may read
    N2143 on
    http://open-std.org/jtc1/sc22/wg21/docs/papers/2007/#mailing2007-01
    and look at the integer and unsigned_integer classes in the synopsis as an
    example.
    When making this I encountered the same problem as you did.
    But integer and unsigned_integer have the same non-static data members. When
    the data members are different, you should be aware of the slicing problem,
    discussed in item 54 of the book mentioned.
    Hope this helps,
    Maarten.
    Maarten Kronenburg, May 22, 2007
    #3
  4. James Kanze Guest

    On May 22, 6:44 pm, "Alf P. Steinbach" <> wrote:
    > * :


    > > Can anybody shed some light on this problem?


    > > class Interface {
    > > public:
    > > Interface() { ...}
    > > virtual ~Interface() { ...}
    > > virtual method() = 0;
    > > };


    > > class Impl1: public Interface {
    > > public:
    > > Impl1() { ...}
    > > Impl1(const Interface&); // problem 1
    > > virtual ~Impl1() { ... }
    > > Impl1& operator=(const Interface&); // problem 2
    > > };


    > > The problem is that the compiler insists on generating the following
    > > methods:
    > > Impl1(const Impl1&); // copy constructor
    > > Impl1& operator=(const Impl1&); // assignment operator
    > > for me.
    > > I do not need these methods.
    > > I do not want these methods.
    > > I would have thought the compiler would call one of my explicit
    > > methods since every Impl1 is also an Interface.


    > No. Both the copy constructor and the copy assignment operator are very
    > special member functions (thus, listend under "Special member
    > functions"). They're generated if they're used and not declared.


    > > Is there some simple trick I am missing here?


    > At the technical C++ level: just declare them.


    I don't think that will do what he wants. If I understand him
    correctly, he wants Impl1( Interface const& ) to be used when
    copying an Interface. In that case, the only solution he has is
    to als define his Impl1( Impl1 const& ) to do exactly the same
    thing.

    > But at the design level, having polymorphic assignment is almost never a
    > good idea.


    > Have you really thought through the consequences, how to handle all
    > combinations of destination and source (e.g., run time errors)?


    Maybe he's implementing the letter/envelope idiom. (But
    somehow, I don't think so, and I think you're right, copy and
    assignment aren't going to work like he wants.)

    --
    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, May 23, 2007
    #4
  5. * James Kanze:
    > On May 22, 6:44 pm, "Alf P. Steinbach" <> wrote:
    >> * :

    >
    >>> Can anybody shed some light on this problem?

    >
    >>> class Interface {
    >>> public:
    >>> Interface() { ...}
    >>> virtual ~Interface() { ...}
    >>> virtual method() = 0;
    >>> };

    >
    >>> class Impl1: public Interface {
    >>> public:
    >>> Impl1() { ...}
    >>> Impl1(const Interface&); // problem 1
    >>> virtual ~Impl1() { ... }
    >>> Impl1& operator=(const Interface&); // problem 2
    >>> };

    >
    >>> The problem is that the compiler insists on generating the following
    >>> methods:
    >>> Impl1(const Impl1&); // copy constructor
    >>> Impl1& operator=(const Impl1&); // assignment operator
    >>> for me.
    >>> I do not need these methods.
    >>> I do not want these methods.
    >>> I would have thought the compiler would call one of my explicit
    >>> methods since every Impl1 is also an Interface.

    >
    >> No. Both the copy constructor and the copy assignment operator are very
    >> special member functions (thus, listend under "Special member
    >> functions"). They're generated if they're used and not declared.

    >
    >>> Is there some simple trick I am missing here?

    >
    >> At the technical C++ level: just declare them.

    >
    > I don't think that will do what he wants. If I understand him
    > correctly, he wants Impl1( Interface const& ) to be used when
    > copying an Interface. In that case, the only solution he has is
    > to als define his Impl1( Impl1 const& ) to do exactly the same
    > thing.


    First off, technicality: a definition is a declaration, so in a C++
    technical interpretation that solution is included in what I said.

    But just declaring them with no definition is, contrary to (the natural
    and most sensible interpretation of) your statement, sufficient to
    guarantee they'll not be invoked.

    Instead of using static_cast it's then convenient to equip the Interface
    class with an explicit asInterface() member function:

    #include <iostream>
    #include <ostream>

    void say( char const s[] ) { std::cout << s << std::endl; }

    class Interface
    {
    public:
    Interface() {}
    virtual ~Interface() {}
    virtual void method() = 0;

    virtual Interface& asInterface() { return *this; }
    };

    class Impl1: public Interface
    {
    private:
    Impl1( Impl1 const& );
    Impl1& operator=( Impl1 const& );

    public:
    Impl1() {}

    Impl1( Interface const& )
    { say( "Copying interface" ); }

    Impl1& operator=( const Interface& )
    { say( "= interface" ); return *this; }

    void method() {}
    };

    int main()
    {
    Impl1 a;
    Impl1 b( a.asInterface() );

    a = b.asInterface();
    }


    >> But at the design level, having polymorphic assignment is almost never a
    >> good idea.

    >
    >> Have you really thought through the consequences, how to handle all
    >> combinations of destination and source (e.g., run time errors)?

    >
    > Maybe he's implementing the letter/envelope idiom. (But
    > somehow, I don't think so, and I think you're right, copy and
    > assignment aren't going to work like he wants.)


    Yes. Instead of copying to existing objects, he should probably be
    considering cloning. And with a restriction to dynamic allocation the
    asInterface function wouldn't be needed because all objects would be
    handled via pointers or references to interfaces.

    --
    A: Because it messes up the order in which people normally read text.
    Q: Why is it such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
    Alf P. Steinbach, May 23, 2007
    #5
    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.

Share This Page