Question

I know it is not allowed in C++, but why? What if it was allowed, what would the problems be?

Answer 1

Judging by your other question, it seems you don’t understand how classes operate. Classes are a collection of functions which operate on data.

Functions themselves contain no memory in a class. The following class:

struct dumb_class
{
    void foo(){}
    void bar(){}
    void baz(){}
    // .. for all eternity

    int i;
};

Has a size of int. No matter how many functions you have ever, this class will only take up the space it takes to operate on an int. When you call a function in this class, the compiler will pass you a pointer to the place where the data in the class is stored; this is the this pointer.

So, the function lie in memory somewhere, loaded once at the beginning of your program, and wait to be called with data to operate on.

Virtual functions are different. The C++ standard does not mandate how the behavior of the virtual functions should go about, only what that behavior should be. Typically, implementations use what’s called a virtual table, or vtable for short. A vtable is a table of function pointers, which like normal functions, only get allocated once.

Take this class, and assume our implementor uses vtables:

struct base { virtual void foo(void); };
struct derived { virtual void foo(void); };

The compiler will need to make two vtables, one for base and one for derived. They will look something like this:

typedef /* some generic function pointer type */ func_ptr;

func_ptr __baseTable[] = {&base::foo}; 
func_ptr __derivedTable[] = {&derived::foo}; 

How does it use this table? When you create an instance of a class above, the compiler slips in a hidden pointer, which will point to the correct vtable. So when you say:

derived d;
base* b = &d;
b->foo();

Upon executing the last line, it goes to the correct table (__derivedTable in this case), goes to the correct index (0 in this case), and calls that function. As you can see, that will end up calling derived::foo, which is exactly what should happen.

Note, for later, this is the same as doing derived::foo(b), passing b as the this pointer.

So, when virtual methods are present, the class of the size will increase by one pointer (the pointer to the vtable.) Multiple inheritance changes this a bit, but it’s mostly the same. You can get more details at C++-FAQ.

Now, to your question. I have:

struct base { virtual void foo(void) = 0; }; // notice the = 0
struct derived { virtual void foo(void); };

and base::foo has no implementation. This makes base::foo a pure abstract function. So, if I were to call it, like above:

derived d;
base* b = &d;
base::foo(b);

What behavior should we expect? Being a pure virtual method, base::foo doesn’t even exist. The above code is undefined behavior, and could do anything from nothing to crashing, with anything in between. (Or worse.)

Think about what a pure abstract function represents. Remember, functions take no data, they only describe how to manipulate data. A pure abstract function says: “I want to call this method and have my data be manipulated. How you do this is up to you.”

So when you say, “Well, let’s call an abstract method”, you’re replying to the above with: “Up to me? No, you do it.” to which it will reply “@#^@#^”. It simply doesn’t make sense to tell someone who’s saying “do this”, “no.”

To answer your question directly:

“why we cannot create an object for an abstract class?”

Hopefully you see now, abstract classes only define the functionality the concrete class should be able to do. The abstract class itself is only a blue-print; you don’t live in blue-prints, you live in houses that implement the blue-prints.