* 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.
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
