Pure Abstract Classes

[Eric]

I was wondering what people thought about the information found at:

http://g.oswego.edu/dl/mood/C++AsIDL.html

Specifically, I am interested in the following recommendation:

----
Since interface classes cannot be directly instantiated, yet serve as
virtual base classes for implementations, the constructors should take
no arguments and should be listed as protected. Also, for similar
reasons, abstract classes should have a no-op virtual destructor, not
one listed as ... = 0.
----

Not being familiar with Doug Lea, I am not certain whether his
recommendations should be treated a genuine Perls of Wisdom or not.

Is this really the right way to do things? Could it lead to unexpected
bugs? If so, what should be payed attention to to avoid these bugs?

The reason I bring this up is that I am working with a pure abstract
class which really should be one. It seems kinda messy to have to
declare non-abstract things in it, destroying the purity of the class,
but doing so would get rid of an annoying compiler warning...and I
definitely like and prefer warning free compiles as it makes it easy to
spot warnings that point to real problems.

 

[Victor Bazarov]

I was wondering what people thought about the information found at:

http://g.oswego.edu/dl/mood/C++AsIDL.html

Specifically, I am interested in the following recommendation:

----
Since interface classes cannot be directly instantiated, yet serve as
virtual base classes for implementations, the constructors should take
no arguments and should be listed as protected. Also, for similar
reasons, abstract classes should have a no-op virtual destructor, not
one listed as ... = 0.
----

Not being familiar with Doug Lea, I am not certain whether his
recommendations should be treated a genuine Perls of Wisdom or not.

Is this really the right way to do things? Could it lead to unexpected
bugs? If so, what should be payed attention to to avoid these bugs?

The reason I bring this up is that I am working with a pure abstract
class which really should be one. It seems kinda messy to have to
declare non-abstract things in it, destroying the purity of the class,
but doing so would get rid of an annoying compiler warning...and I
definitely like and prefer warning free compiles as it makes it easy
to spot warnings that point to real problems.

Sounds close to what I consider "good C++". No unexpected bugs AFAICS.

"The right way to do things" depends on what your design goals are. If
it's "C++ As IDL", sure, it's the right way. In our application there
are almost no pure "interfaces". Even abstract classes can have data
(state) and may need initialisation other than default.

V

 

[=?ISO-8859-1?Q?Erik_Wikstr=F6m?=]

I was wondering what people thought about the information found at:

http://g.oswego.edu/dl/mood/C++AsIDL.html

Specifically, I am interested in the following recommendation:

----
Since interface classes cannot be directly instantiated, yet serve as
virtual base classes for implementations, the constructors should take
no arguments and should be listed as protected. Also, for similar
reasons, abstract classes should have a no-op virtual destructor, not
one listed as ... = 0.
----

The thing about the destructor is true, it's also in the FAQ [1]. It's
not really clear from the quote whether he thinks that the constructor
should be pure virtual or not, looking at the article it seems not.
Personally I can't see any reason to declare a constructor except to
prevent people from trying to instantiate the class. But since it's
abstract that's not possible anyway.

1. http://www.parashift.com/c++-faq-lite/virtual-functions.html#faq-20.7

 

[Alf P. Steinbach]

* Eric:

I was wondering what people thought about the information found at:

http://g.oswego.edu/dl/mood/C++AsIDL.html

Specifically, I am interested in the following recommendation:

----
Since interface classes cannot be directly instantiated, yet serve as
virtual base classes for implementations, the constructors should take
no arguments and should be listed as protected. Also, for similar
reasons, abstract classes should have a no-op virtual destructor, not
one listed as ... = 0.
----

Not being familiar with Doug Lea, I am not certain whether his
recommendations should be treated a genuine Perls of Wisdom or not.

Is this really the right way to do things? Could it lead to unexpected
bugs? If so, what should be payed attention to to avoid these bugs?

The reason I bring this up is that I am working with a pure abstract
class which really should be one. It seems kinda messy to have to
declare non-abstract things in it, destroying the purity of the class,
but doing so would get rid of an annoying compiler warning...and I
definitely like and prefer warning free compiles as it makes it easy to
spot warnings that point to real problems.

First, although the ideal in C++ is that interface classes serve as
virtual base classes, that ideal is often compromised due to reasons
such as efficiency or having to work with an existing framework, and
sticking to the ideal would mean not creating that program.

Second, there's nothing inherently wrong about a pure virtual
destructor, and it's a not uncommon convention to "document" a class as
abstract by having a pure virtual destructor at the top of the class'
code. But if a destructor is declared, it should also be implemented.
Including that a pure virtual destructor should always be implemented
(the implementation will be called non-virtually). A good linker will
ensure that. But unfortunately you can't count on that.

Third, the notion that an abstract class should have a no-op destructor
is IMO an academic purist view of abstract classes where they don't
manage resources. IMO that's just silly, and not very practical. The
early Smalltalk notion of an abstract class, a class with one or more
methods as "subclass responsibility", is IMO much better suited to
actual programming, but the subset of abstract classes that don't
enforce class invariants directly or leave all resource allocation and
deallocation to derived classes and only provide ways of checking the
invariant, are very important -- e.g., they include interface classes.

Having said that, the advice quoted above (I didn't follow the link) is
good, but as general advice, not as an absolute guideline.

As always, it's better to do what you think best -- because you
understand that, and can learn from it and fix it if it turns out to be
less than ideal -- than to blindly follow advice you don't understand.

 

[Cy Edmunds]

I was wondering what people thought about the information found at:

http://g.oswego.edu/dl/mood/C++AsIDL.html

Specifically, I am interested in the following recommendation:

----
Since interface classes cannot be directly instantiated, yet serve as
virtual base classes for implementations, the constructors should take
no arguments and should be listed as protected. Also, for similar
reasons, abstract classes should have a no-op virtual destructor, not
one listed as ... = 0.
----

Not being familiar with Doug Lea, I am not certain whether his
recommendations should be treated a genuine Perls of Wisdom or not.

Is this really the right way to do things? Could it lead to unexpected
bugs? If so, what should be payed attention to to avoid these bugs?

The reason I bring this up is that I am working with a pure abstract
class which really should be one. It seems kinda messy to have to
declare non-abstract things in it, destroying the purity of the class,
but doing so would get rid of an annoying compiler warning...and I
definitely like and prefer warning free compiles as it makes it easy to
spot warnings that point to real problems.

In spite of my great respect for some of the other responders who have a
different view, it is my opinion that "pure abstract classes" should NEVER
have any state to initialize and therefore should never have constructors at
all. I will defend this position by pointing out that if you want a starting
point which has a state, you can always derive one from the pure abstract
class and derive the rest of your classes from there.

Otherwise it ain't pure. Just my opinion.

The no-op virtual destructor is a good idea. If any of the derived classes
have non-trivial destructors it may prevent a hard-to-find resource leak.

Cy