[comp.lang.c++] Objects of type <abstract-class> ?????

rfg@ics.uci.edu (Ron Guilmette) (12/25/89)

In the new C++ Reference Manual, it is stated that:

	"An abstract class is a class that can only be used as a base class
	of some other class; no objects of an abstract class may be created
	EXCEPT AS SUB-OBJECTS OF SOME OTHER CLASS".

(The added emphasis is mine.)

It is that last part that has me really confused.  Can sombody please
tell me how (or why) it makes any sense to allow this exception to
the (otherwise reasonable) rule?

The first part of the rule is reasonable because it attempts to insure
that objects of an abstract class (which is essentially an incomplete
thing) are not accidently created.

However the exception allowed for "sub-objects" of other objects seems
to make the whole rule pointless, because you can now circumvent the
general rule and create objects of type <abstract-class>.

A simple example of the problems that this "exception" to the general rule
can cause is illustrated below:

	struct abstract {
		virtual void foobar () = 0;
	};

	struct concrete {
		abstract	abstract_member;
	};

	concrete concrete_object;

	main ()
	{
		concrete_object.foobar ();	// is this legal ????
	}

Note that the call to foobar() within main() is certain to be invalid,
and will generally cause a segfault.

So what's going on here?  It seems that the declaration of objects of
abstract types should be either always allowed or never allowed.  Having
it be "sometimes" allowed just doesn't make sense to me.

// rfg

ldg@drywit.ATT.COM (XMRB30000-GibbonsD(DRR6702)262) (12/27/89)

From article <25955350.5608@paris.ics.uci.edu>, by rfg@ics.uci.edu (Ron Guilmette):
> 
> In the new C++ Reference Manual, it is stated that:
> 
> 	"An abstract class is a class that can only be used as a base class
> 	of some other class; no objects of an abstract class may be created
> 	EXCEPT AS SUB-OBJECTS OF SOME OTHER CLASS".
> 

Looks like the problem here is the interpretation of "SUB-OBJECT."
I didn't very look hard, but the reference manual manual seems to use this 
term without defining it. However, the term is used elsewhere (see Multiple 
Base Classes) in the context of referring to that part of an "object" containing
the members inherited from a base class.

> However the exception allowed for "sub-objects" of other objects seems
> to make the whole rule pointless, because you can now circumvent the
> general rule and create objects of type <abstract-class>.
> 
> A simple example of the problems that this "exception" to the general rule
> can cause is illustrated below:
> 
> 	struct abstract {
> 		virtual void foobar () = 0;
> 	};
> 
> 	struct concrete {
> 		abstract	abstract_member;
> 	};
> 
> 	concrete concrete_object;
> 
> 	main ()
> 	{
> 		concrete_object.foobar ();	// is this legal ????
> 	}

No. You cannot declare or create an object of type "abstract,"
which is what you were doing when you declared "abstract_member."
What you CAN do is this:

struct abstract {
	virtual void foobar() = 0;
};

struct concrete : public abstract {
	void foobar();
};

void concrete::foobar() { // concrete foobar stuff }

concrete concrete_object;

main()
{
	concrete_object.foobar();
}

> 
> So what's going on here?  It seems that the declaration of objects of
> abstract types should be either always allowed or never allowed.  Having
> it be "sometimes" allowed just doesn't make sense to me.

The declaration of abstract objects is never allowed. There is
no "sometimes" loophole.
--
--------------------------------------------------------------------------------
-- Doug Gibbons			| ldg@druhi.ATT.COM or att!druhi!ldg
-- AT&T Bell Laboratories 
-- Denver CO