question about class instantiation

[Devon Null]

I have been exploring the concept of abstract classes and I was curious
- If I do not define a base class as abstract, will it be instantiated
(hope that is the right word) when a derived class is created?

if ( answer == false )
{
Would the idea of an abstract class simply be used to enforce integrity
of the classes by disallowing the abstract class to be instantiated, or
are there other purposes for it?
}
else if ( answer == true )
{
I'm guessing to prevent this would be the "why" and "when" of using
them, as well as enforce class integrity.
}

Is there a "proper" way of using/creating abstract classes?

Thanks

P.S. I apologize if this info is readily available on Google, but I did
a cursory search and came up with a lot of stuff that, while
interesting, did nothing to answer my very specific question. I know
that a vast quantity of the collected human intelligence on the subject
is here, so I thought I might go to the fount of knowledge directly.
Thanks again.

[Victor Bazarov]

Devon Null wrote:

I have been exploring the concept of abstract classes and I was
curious - If I do not define a base class as abstract, will it be
instantiated (hope that is the right word) when a derived class is
created?

Any base class subobject is instantiated as part of the derived
class object. The "abstract" trait prohibits from stand-alone
instantiation of the object.

>
if ( answer == false )
{
Would the idea of an abstract class simply be used to enforce
integrity of the classes by disallowing the abstract class to be
instantiated, or are there other purposes for it?

The class' being abstract means it doesn't have the behaviour
completely defined, which means that a stand-alone object of
that type cannot exist since it cannot _behave_, in some special
cases.

Prohibiting instantiation of an abstract class is a preventative
measure. The compiler doesn't have to guess whether this class
is ever used in a way that would have undefined behaviour. Here
is an example of what _might_ be OK:

struct Abstract {
virtual void foo() = 0;
};

int main() {
Abstract a;
}

In that program 'foo' behaviour is never invoked, which should
be OK, since there is no undefined behaviour anywhere. But
making the compiler analyze all possible situations and allow
the ones like this, but disallow others, would be too complex.
That's why the Standard simply disallows creation of 'Abstract'
object.

}
else if ( answer == true )
{
I'm guessing to prevent this would be the "why" and "when" of using
them, as well as enforce class integrity.
}

Is there a "proper" way of using/creating abstract classes?

The only way to "properly" use abstract classes is to have them
as arguments passed by reference or pointer, and instantiate them
ONLY as base class subobjects.

>
Thanks

P.S. I apologize if this info is readily available on Google, but I
did a cursory search and came up with a lot of stuff that, while
interesting, did nothing to answer my very specific question. I know
that a vast quantity of the collected human intelligence on the
subject is here, so I thought I might go to the fount of knowledge
directly. Thanks again.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Devon Null]

Victor Bazarov wrote:

Devon Null wrote:

>I have been exploring the concept of abstract classes and I was
curious - If I do not define a base class as abstract, will it be
instantiated (hope that is the right word) when a derived class is
created?

Any base class sub-object is instantiated as part of the derived
class object. The "abstract" trait prohibits from stand-alone
instantiation of the object.

Let's say I had class bar which is derived from abstract class foo,
would both classes take memory:

((total mem usage == (abstract foo) + bar) < (total mem usage ==
(non-abstract foo) + bar))

or would the mem requirements still be the same regardless if foo was
abstract:

((total mem usage == (abstract foo) + bar) == (total mem usage ==
(non-abstract foo) + bar))

>if ( answer == false )
{
Would the idea of an abstract class simply be used to enforce
integrity of the classes by disallowing the abstract class to be
instantiated, or are there other purposes for it?

The class' being abstract means it doesn't have the behaviour
completely defined, which means that a stand-alone object of
that type cannot exist since it cannot _behave_, in some special
cases.

Prohibiting instantiation of an abstract class is a preventative
measure. The compiler doesn't have to guess whether this class
is ever used in a way that would have undefined behaviour. Here
is an example of what _might_ be OK:

struct Abstract {
virtual void foo() = 0;
};

int main() {
Abstract a;
}

In that program 'foo' behaviour is never invoked, which should
be OK, since there is no undefined behaviour anywhere. But
making the compiler analyze all possible situations and allow
the ones like this, but disallow others, would be too complex.
That's why the Standard simply disallows creation of 'Abstract'
object.

>}
else if ( answer == true )
{
I'm guessing to prevent this would be the "why" and "when" of using
them, as well as enforce class integrity.
}

Is there a "proper" way of using/creating abstract classes?

The only way to "properly" use abstract classes is to have them
as arguments passed by reference or pointer, and instantiate them
ONLY as base class sub-objects.

Pardon any ignorance, but could you please explain/clarify this
statement? I do get that part about it only being a base class. Kinda
useless for anything else if you can't instantiate it.

>Thanks

P.S. I apologize if this info is readily available on Google, but I
did a cursory search and came up with a lot of stuff that, while
interesting, did nothing to answer my very specific question. I know
that a vast quantity of the collected human intelligence on the
subject is here, so I thought I might go to the fount of knowledge
directly. Thanks again.

V

--
[there are no x's in my email]

I have the right to remain silent
(and should probably use it as much as possible)
Anything I type can and will be used against me
in a court of idiocy
I have the right to be wrong
(and probably am)
If I can not furnish my own wrongness
I'm sure someone will provide it for me.

[Victor Bazarov]

Devon Null wrote:

Victor Bazarov wrote:

>Devon Null wrote:

>>I have been exploring the concept of abstract classes and I was
curious - If I do not define a base class as abstract, will it be
instantiated (hope that is the right word) when a derived class is
created?

Any base class sub-object is instantiated as part of the derived
class object. The "abstract" trait prohibits from stand-alone
instantiation of the object.

Let's say I had class bar which is derived from abstract class foo,
would both classes take memory:

((total mem usage == (abstract foo) + bar) < (total mem usage ==
(non-abstract foo) + bar))

or would the mem requirements still be the same regardless if foo was
abstract:

((total mem usage == (abstract foo) + bar) == (total mem usage ==
(non-abstract foo) + bar))

The amount of memory taken up by an instance of the class has nothing
to do with its abstractness. The size is calculated from the sizes
of base class subobjects, sizes of data members, additional padding
and other implementation-defined things (like virtual function table
pointer, for example).

>>[..]
Is there a "proper" way of using/creating abstract classes?

The only way to "properly" use abstract classes is to have them
as arguments passed by reference or pointer, and instantiate them
ONLY as base class sub-objects.

Pardon any ignorance, but could you please explain/clarify this
statement? I do get that part about it only being a base class. Kinda
useless for anything else if you can't instantiate it.

I am not sure what clarification you need, but I'll try.

struct Abstract {
virtual void foo() = 0;
};

void func(Abstract& a) {
a.foo(); // you dn't know whether it's a stand-alone instance
}

void func(Abstract* pa) {
pa->foo();
}
//////////////////////////////////////
struct Derived : Abstract {
void foo() {}
};

int main() {
Derived d;
foo(d);
foo(&d);
}

Now, the portion before the comment is where the abstract class is
used. The only way to use an instance of it is in a function where
the instance (the act of its creation aside for a moment) is passed
by reference or by pointer.

In the portion after the comment - the only way to instantiate the
abstract class, as a base class to non-abstract class. In the
'main' function 'd' is an instance of a concrete type.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Devon Null]

Victor Bazarov wrote:

>>>[..]
Is there a "proper" way of using/creating abstract classes?
The only way to "properly" use abstract classes is to have them
as arguments passed by reference or pointer, and instantiate them
ONLY as base class sub-objects.

Pardon any ignorance, but could you please explain/clarify this
statement? I do get that part about it only being a base class. Kinda
useless for anything else if you can't instantiate it.

I am not sure what clarification you need, but I'll try.

struct Abstract {
virtual void foo() = 0;
};

void func(Abstract& a) {
a.foo(); // you don't know whether it's a stand-alone instance
}

void func(Abstract* pa) {
pa->foo();
}
//////////////////////////////////////
struct Derived : Abstract {
void foo() {}
};

int main() {
Derived d;
foo(d);
foo(&d);
}

Now, the portion before the comment is where the abstract class is
used. The only way to use an instance of it is in a function where
the instance (the act of its creation aside for a moment) is passed
by reference or by pointer.

In the portion after the comment - the only way to instantiate the
abstract class, as a base class to non-abstract class. In the
'main' function 'd' is an instance of a concrete type.

V

The clarification was in the wording. It was the line "The only way to
"properly" use abstract classes is to have them as arguments passed by
reference or pointer." I thought this (above) was what you meant, but
for some reason my brain was having trouble piecing it together. Thanks
for all your help.

DN

--
[there are no x's in my email]

I have the right to remain silent
(and should probably use it as much as possible)
Anything I type can and will be used against me
in a court of idiocy
I have the right to be wrong
(and probably am)
If I can not furnish my own wrongness
I'm sure someone will provide it for me.