Information Regarding Pure Virtual Functions

Quote:

---

The main difference between a pure virtual function and a regular virtual function is _______.
A. the return type
B. the inheritance properties
C. a pure virtual function cannot have an implementation.
D. the location in the class

Posted by Mister C

---

Sometime before this question was posted in this board and we had a lengthy discussion.

Many would pick 'C'.

Reality:

The only difference between a pure virtual function and regular virtual function is that pure virtual function makes a class "Abstract" and regular virtual function does not make the class "Abstract"

Polymorphic OOP made the below mentioned statement
Pure virtual destructors MUST have a body

Added Information:
Whether a virtual function is pure or regular, it CAN have a body.

Hope this is of some help to your folks

>Whether a virtual function is pure or regular, it CAN have a body.

Please show me example code of a pure virtual function WITH a body.

Why did you make a new thread about this? You should've bumped the old one if you wanted to contribute more to it.

We already made this point, there is no reason for you to bring it up again...

Anyways, here's an example Davros:

Code:

---

class A
{
    virtual void Blah() = 0;
};

void A::Blah()
{
}

---

For Davros

I was just going thru a web site,
I encountered a statement saying that

"( pure )virtual functions can be private or public."

now what's the using of keeping a ( pure ) virtual function private.

They can be protected as well, not just public and private.

The primary reason I can think of that one would make a pure virtual function private are for affecting the way that the object can be dealt with through pointers and/or references.

It all stems primarily from the fact that a virtual function can be called from a member function in the base, so the member function can be called from within the base class member functions, just not externally.

Also, remember that you can change the access of a member function in derived versions of the class. What's private in the base class isn't necissarily private in a child.

Let's say you have a pure virtual function in a class "Base," but you only want that function to be called through pointers to its children. In other words, you want to be able to call the function through a pointer to a child or an object of a child type, but never through a pointer to its base.

One solution would be to just not put the function in the Base class, but the problem with this is that it doesn't hold the logic that all of the children should have that member function. You want to keep that logic but make it so you can't explicitly call it through a pointer to a base object.

If, instead, you make the member function pure virtual and private, you're ensuring that people MUST make their own versions of that virtual function in the Base type's children if they want to instantiate those types.

Then, if necissary, the virtual function can be made protected, public, or left private, to take advantage of that access specifier.

Example:

Code:

---

#include<iostream>

class Base
{
public:
    void DoStuff();
private:
    virtual void Func() = 0;
};

class Child
    : public Base
{
public:
    virtual void Func();
};

class BadChild
    : public Base
{
};

void Base::DoStuff()
{
    /* Stuff Goes Here */

    Func(); // Perfectly valid
}

void Child::Func()
{
    std::cout << "B\n";
}

int main()
{
    Child ChildObject;
    //BadChild BadChildObject; //Invalid, Func was not defined

    Base& BaseObjectReference = ChildObject;

    ChildObject.Func(); // This works!!!

    BaseObjectReference.DoStuff(); // This works!!!

    //BaseObjectReference.Func(); //Invalid! Func is private!!!

    return 0;
}

---

Oh the many wonders of OOP

EDIT: Disabled those smilies