Why an Abstract Base Class cannot be instantiated ?

[Dev]

Hello,

Why an Abstract Base Class cannot be instantiated ?

Does anybody know of the object construction internals ?

What is the missing information that prevents the construction ?

TIA.
Dev

[Jacques Labuschagne]

Dev wrote:

Hello,

Why an Abstract Base Class cannot be instantiated ?

Does anybody know of the object construction internals ?

What is the missing information that prevents the construction ?

TIA.
Dev

An abstract base class is one with pure virtual functions, i.e. it
defines an interface and not a complete implementation. You can't
instantiate it because some of its functions don't have definitions.
What would you expect to happen if you could call one of these
non-existant functions?

If you find yourself trying to instantiate an ABC then there's probably
something wrong with your design.

Jacques.

[Dev]

I am trying to understand the instantiation from a compiler author
perspective.

Dev.

[Jacques Labuschagne]

Dev wrote:

I am trying to understand the instantiation from a compiler author
perspective.

My answer stands. The instantiation would not be meaningful because the
object has functions missing. I've never written a compiler, but I
imagine that you'd run into problems trying to populate the virtual
function table with pointers to functions that don't exist. Even if you
could do it, it would be useless to the user.

Jacques.

[Dev]

virtual f()=0;
is in effect suggesting a null function pointer.

Is this all or is there something more to this ?

Dev.

[Greg]

Jacques Labuschagne wrote:

Dev wrote:

I am trying to understand the instantiation from a compiler author
perspective.

My answer stands. The instantiation would not be meaningful because the
object has functions missing. I've never written a compiler, but I
imagine that you'd run into problems trying to populate the virtual
function table with pointers to functions that don't exist. Even if you
could do it, it would be useless to the user.

Jacques.

But even when the abstract class provides definitions for each of its
pure virtual functions, the class still cannot be directly
instantiated. There really is no compelling technical reason why
abstract classes could not be instantiated; after the language rules
could simply be adjusted and have the compiler provide an empty
definition for a pure virtual function - in much the same way that the
compiler provides a default constructor when needed. Instead, the
prohibition against instantiating an abstract class is a deliberate
feature of the language. An abstract class cannot be instantiated
because the definition of an abstract class is one that cannot be
instantiated.

In C++, abstract classes help keep separate class interface from
implementation. An abstract class need specify only an interface.
Because it cannot be instantiated, it has no need no provide any
implementation of its own. Instead the pure virtual mechanism forces
subclasses to provide part or all of the implementation. By keeping the
two separate, the resulting code is more portable, has few dependencies
and is overall "cleaner" than one in which the interface and
implementation are tightly intertwined.

Greg

[rookkey]

"Dev" <de*********@gmail.com> wrote in
news:11**********************@g44g2000cwa.googlegr oups.com:

virtual f()=0;
is in effect suggesting a null function pointer.

The "=0" hanging off the end of the function declaration is just a
syntactical peculiarity that says a given function is "pure" virtual.

Bjarne Stroustroup in his "The Design and Evolution of C++" book says that
"=0" was chosen as the way to declare pure virtual functions because the
C++ language designers did not want to go through the pain of introducing a
new keyword (such as "pure") to the language. If a new keyword was
introduced, it would break all the existing C++ code that uses that
identifier for its variables, class names and the like. Using "=0" to
declare such functions would not break any previously legal code.

So, the "=0" syntax has nothing to do with "null functions" or nullness at
all. It's just another one of those compatibility quirks that give C++ its
spicy flavor.

[Cy Edmunds]

"Dev" <de*********@gmail.com> wrote in message
news:11**********************@g43g2000cwa.googlegr oups.com...

Hello,

Why an Abstract Base Class cannot be instantiated ?

Does anybody know of the object construction internals ?

What is the missing information that prevents the construction ?

TIA.
Dev

Actually, an ABC can be instantiated. You just can't declare a variable of
that type. Consider:

class base
{
public:
base() {/* ABC "base" is instantiated at this point */}
virtual void pure() = 0;
virtual ~base() {}
};

class derived : public base
{
public:
virual void pure() {}
};

int main()
{
derived d;
}

Note that within base::base() the object is truly a "base", not a "derived".
Just don't try to call base::pure() from base::base().

This may sound like a nit pick, but it bears on your point. Given that ABC's
are actually instantiated as part of the construction process, it is clear
that the language could have allowed you to declare ABC variables. However,
I'm glad it didn't; such usage would have been very dangerous.

--
Cy
http://home.rochester.rr.com/cyhome/

[Greg]

Cy Edmunds wrote:

"Dev" <de*********@gmail.com> wrote in message
news:11**********************@g43g2000cwa.googlegr oups.com...

Hello,

Why an Abstract Base Class cannot be instantiated ?

Does anybody know of the object construction internals ?

What is the missing information that prevents the construction ?

TIA.
Dev

Actually, an ABC can be instantiated. You just can't declare a variable of
that type. Consider:

I don't think there is much of a distinction to be made here. Declaring
a variable of a class type instantiates an instance of that class type.

class base
{
public:
base() {/* ABC "base" is instantiated at this point */}
The base class constructor initializes - but does not instantiate - an
instance of the class base. The instantiation of this instance would
had to have occured earlier in the program's execution in order for the
object to be under construction and be executing this code.
virtual void pure() = 0;
virtual ~base() {}
};

class derived : public base
{
public:
virual void pure() {}
};

int main()
{
derived d;
}

Note that within base::base() the object is truly a "base", not a "derived".
Just don't try to call base::pure() from base::base().
It's perfectly legal to call base::pure from base::base, but doing so
imposes a requirement upon the program. The Standard states that if a
pure virtual function is explicitly called within a program, than that
program must implement the pure virtual method that was called. So in
this case, should base::base call base::pure, the program would then be
obligated to provide an implementation for base::pure (which may simply
do nothing) in order to ensure that the call to the pure virtual method
invokes an actual, defined method.

This may sound like a nit pick, but it bears on your point. Given that ABC's
are actually instantiated as part of the construction process, it is clear
that the language could have allowed you to declare ABC variables. However,
I'm glad it didn't; such usage would have been very dangerous.

It's prefectly legal to declare a pointer to an abstract class and then
call pure virtual methods through the pointer. But as I just pointed
out, doing so forces the abstract class to implement whatever pure
virtual methods are being called directly. But whether its virtual
methods are defined or not, the class itself remains abstract and, as
such, cannot be directly instantiated.

Greg