I see no difference in an inheirited non-virtual method and an inheirited virtual method

Discussion in 'C++' started by jlopes, Nov 19, 2004.

  1. jlopes

    jlopes Guest

    I'm looking at the differences between these to forms and see no
    difference in their use. When accessed through a derived class.

    class ABase
    {
    public:
    virtual void filter(){ /* some code */ }
    };

    class D_of_ABase : public ABase
    {
    public:
    };

    class Base
    {
    public:
    void filter(){ /* some code */ }
    };

    class Child : public Base
    {
    publc:
    };

    void main()
    {
    Child* child = new Child();
    D_of_ABase* doab = new D_of_ABase();

    child->filter();
    doab->filter();
    }
    jlopes, Nov 19, 2004
    #1
    1. Advertising

  2. jlopes

    Phlip Guest

    jlopes wrote:

    > I'm looking at the differences between these to forms and see no
    > difference in their use. When accessed through a derived class.
    >
    > class ABase
    > {
    > public:
    > virtual void filter(){ /* some code */ }
    > };
    >
    > class D_of_ABase : public ABase
    > {
    > public:
    > };


    One generally has no reason to inherit unless one overrides a virtual class.

    > class Base
    > {
    > public:
    > void filter(){ /* some code */ }
    > };
    >
    > class Child : public Base
    > {
    > publc:
    > };
    >
    > void main()


    'void main' will make your 'nads drop off. Use 'int main'.

    > {
    > Child* child = new Child();
    > D_of_ABase* doab = new D_of_ABase();
    >
    > child->filter();
    > doab->filter();
    > }


    Suppose Child overrode filter() too. Now suppose you have this function:

    int foo(Base & b)
    {
    b.filter();
    }

    Now you can pass any Base object into foo(), or any Child object, or any
    other object that inherits Base. The behavior of filter() will change. This
    allows callers to customize foo()'s behavior without changing its source.

    --
    Phlip
    http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
    Phlip, Nov 19, 2004
    #2
    1. Advertising

  3. "jlopes" <> wrote in message
    news:...
    > I'm looking at the differences between these to forms and see no
    > difference in their use. When accessed through a derived class.
    >
    > class ABase
    > {
    > public:
    > virtual void filter(){ /* some code */ }
    > };
    >
    > class D_of_ABase : public ABase
    > {
    > public:
    > };
    >
    > class Base
    > {
    > public:
    > void filter(){ /* some code */ }
    > };
    >
    > class Child : public Base
    > {
    > publc:
    > };
    >
    > void main()
    > {
    > Child* child = new Child();
    > D_of_ABase* doab = new D_of_ABase();
    >
    > child->filter();
    > doab->filter();
    > }


    Even if you do not override the inherited method, you can still see
    diferences if the following conditions are met:

    - some class E_ derives from class D_of_ABase and E_ overrides filter()
    - you use references or pointers to class D_of_ABase
    - you do not initialize the reference or pointer based of objects you
    create,
    but based of objects you receive from some other module or library
    - the other module or library knows or defines class E_ and actualy
    provides you
    with references/pointers to objects of class E_ (this would be
    perfectly legal C++)

    then when you would call filter() through your reference/pointer to
    C_of_ABase, you
    will have the surprise of getting yourself a call to some other override of
    filter() then the one in ABase (namely the one form E_).

    Should you have used classes Base and Child in my example, you would have no
    such surprise.

    I think you can still explicitly call (with no surprises) the inherited
    version of filter() like this:

    D_of_ABase &Dobj = InvokeDObjectFactory() //Get reference to D from
    outside
    Dobj.ABase::filter() // Explicitly call the base class
    override, no matter
    // what was provided with the
    reference form outside

    "Timothy Madden"
    Romania
    Timothy Madden, Nov 19, 2004
    #3
  4. "jlopes" <> wrote in message
    news:...
    > I'm looking at the differences between these to forms and see no
    > difference in their use. When accessed through a derived class.
    >
    > class ABase
    > {
    > public:
    > virtual void filter(){ /* some code */ }
    > };
    >
    > class D_of_ABase : public ABase
    > {
    > public:
    > };
    >
    > class Base
    > {
    > public:
    > void filter(){ /* some code */ }
    > };
    >
    > class Child : public Base
    > {
    > publc:
    > };
    >
    > void main()
    > {
    > Child* child = new Child();
    > D_of_ABase* doab = new D_of_ABase();
    >
    > child->filter();
    > doab->filter();
    > }


    Even if you do not override the inherited method, you can still see
    diferences if the following conditions are met:

    - some class E_ derives from class D_of_ABase and E_ overrides filter()
    - you use references or pointers to class D_of_ABase
    - you do not initialize the reference or pointer based of objects you
    create,
    but based of objects you receive from some other module or library
    - the other module or library knows or defines class E_ and actualy
    provides you
    with references/pointers to objects of class E_ (this would be
    perfectly legal C++)

    then when you would call filter() through your reference/pointer to
    C_of_ABase, you
    will have the surprise of getting yourself a call to some other override of
    filter() then the one in ABase (namely the one form E_).

    Should you have used classes Base and Child in my example, you would have no
    such surprise.

    I think you can still explicitly call (with no surprises) the inherited
    version of filter() like this:

    D_of_ABase &Dobj = InvokeDObjectFactory() //Get reference to D from
    outside
    Dobj.ABase::filter() // Explicitly call the base class
    override, no matter
    // what was provided with the
    reference form outside

    "Timothy Madden"
    Romania
    Timothy Madden, Nov 19, 2004
    #4
  5. "jlopes" <> wrote in message
    news:...
    > I'm looking at the differences between these to forms and see no
    > difference in their use. When accessed through a derived class.
    >
    > class ABase
    > {
    > public:
    > virtual void filter(){ /* some code */ }
    > };
    >
    > class D_of_ABase : public ABase
    > {
    > public:
    > };
    >
    > class Base
    > {
    > public:
    > void filter(){ /* some code */ }
    > };
    >
    > class Child : public Base
    > {
    > publc:
    > };
    >
    > void main()
    > {
    > Child* child = new Child();
    > D_of_ABase* doab = new D_of_ABase();
    >
    > child->filter();
    > doab->filter();
    > }


    Even if you do not override the inherited method, you can still see
    diferences if the following conditions are met:

    - some class E_ derives from class D_of_ABase and E_ overrides filter()
    - you use references or pointers to class D_of_ABase
    - you do not initialize the reference or pointer based of objects you
    create,
    but based of objects you receive from some other module or library
    - the other module or library knows or defines class E_ and actualy
    provides you
    with references/pointers to objects of class E_ (this would be
    perfectly legal C++)

    then when you would call filter() through your reference/pointer to
    C_of_ABase, you
    will have the surprise of getting yourself a call to some other override of
    filter() then the one in ABase (namely the one form E_).

    Should you have used classes Base and Child in my example, you would have no
    such surprise.

    I think you can still explicitly call (with no surprises) the inherited
    version of filter() like this:

    D_of_ABase &Dobj = InvokeDObjectFactory() //Get reference to D from
    outside
    Dobj.ABase::filter() // Explicitly call the base class
    override, no matter
    // what was provided with the
    reference form outside

    "Timothy Madden"
    Romania
    Timothy Madden, Nov 19, 2004
    #5
  6. "jlopes" <> skrev i en meddelelse
    news:...
    > I'm looking at the differences between these to forms and see no
    > difference in their use. When accessed through a derived class.
    >
    > class ABase
    > {
    > public:
    > virtual void filter(){ /* some code */ }

    When having a virtual function you sould alway include a virtual destructor:
    virtual ~ABase() {}
    > };
    >
    > class D_of_ABase : public ABase
    > {
    > public:
    > };
    >
    > class Base
    > {
    > public:
    > void filter(){ /* some code */ }
    > };
    >
    > class Child : public Base
    > {
    > publc:
    > };
    >
    > void main()

    should be int main()
    > {
    > Child* child = new Child();
    > D_of_ABase* doab = new D_of_ABase();
    >
    > child->filter();
    > doab->filter();
    > }


    There is no difference here as you do not override the virtual function, but
    try doing that (print some statement in each function) and see what happens
    here:

    int main()
    {
    Base *base = new Child();
    ABase *abase = new D_of_ABase();
    base->filter();
    abase->filter();
    }

    /Peter
    Peter Koch Larsen, Nov 19, 2004
    #6
  7. jlopes

    jeffc Guest

    "Phlip" <> wrote in message
    news:u3lnd.25977$...
    >
    > One generally has no reason to inherit unless one overrides a virtual class.


    He means to say, "unless one overrides a virtual function." If you don't
    override the function, then there is no point to it.
    jeffc, Nov 19, 2004
    #7
  8. jlopes

    jlopes Guest

    "Phlip" <> wrote in message news:<u3lnd.25977$>...
    > jlopes wrote:
    >
    > > I'm looking at the differences between these to forms and see no
    > > difference in their use. When accessed through a derived class.
    > >
    > > class ABase
    > > {
    > > public:
    > > virtual void filter(){ /* some code */ }
    > > };
    > >
    > > class D_of_ABase : public ABase
    > > {
    > > public:
    > > };

    >
    > One generally has no reason to inherit unless one overrides a virtual class.
    >
    > > class Base
    > > {
    > > public:
    > > void filter(){ /* some code */ }
    > > };
    > >
    > > class Child : public Base
    > > {
    > > publc:
    > > };
    > >
    > > void main()

    >
    > 'void main' will make your 'nads drop off. Use 'int main'.
    >
    > > {
    > > Child* child = new Child();
    > > D_of_ABase* doab = new D_of_ABase();
    > >
    > > child->filter();
    > > doab->filter();
    > > }

    >
    > Suppose Child overrode filter() too. Now suppose you have this function:
    >
    > int foo(Base & b)
    > {
    > b.filter();
    > }
    >
    > Now you can pass any Base object into foo(), or any Child object, or any
    > other object that inherits Base. The behavior of filter() will change. This
    > allows callers to customize foo()'s behavior without changing its source.


    Thanks Phil

    Your thought the in general there is no need to inherit is an answer
    closer to what I'm looking for. If one has a basic set of behavior for
    a given set of objects, and the individual objects has distinct
    behavior, they would inherit behavior from the common object
    (Polymorphisim). As for the "void main" heh just wanted the code to
    compile, sorry the code was not politically correct. As for the foo()
    method heh polymorphism I'm aware of.

    My quesstion was centered round to virtual or not to virtual.
    jlopes, Nov 19, 2004
    #8
    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. Flip
    Replies:
    3
    Views:
    961
    Tony Morris
    Feb 9, 2004
  2. jlopes
    Replies:
    5
    Views:
    446
    le ténébreux
    Nov 19, 2004
  3. Steve Kershaw
    Replies:
    1
    Views:
    344
    Brennan Stehling
    Sep 26, 2006
  4. Replies:
    11
    Views:
    684
    James Kanze
    Sep 10, 2006
  5. Sally
    Replies:
    0
    Views:
    104
    Sally
    Apr 13, 2004
Loading...

Share This Page