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

[jlopes]

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();
}

 

[Phlip]

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.

 

[Timothy Madden]

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]

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]

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

 

[Peter Koch Larsen]

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

 

[jeffc]

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.

 

[jlopes]

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


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


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.