[boost] Re: ABC similar to noncopyable

From: Mark Borgerding (mborgerding_at_[hidden])
Date: 2000-02-23 10:59:00

"miki jovanovic" <mik-_at_[hidden]> wrote: 
original article:http://www.egroups.com/group/boost/?start=2234
> 
> Hello all,
> 
> What is you opinion, does it make sence to have class like this?
> 
>    /*
>     * abc
>     *
>     * Classes should inherit from this class if they are abstract base
> classes.
>     * abc ensures that the destructor is virtual.
>     */
>    class abc {
>       protected:
>          abc() {}
>          virtual ~abc() {}
>    };
> 
> The idea is sort of similar as with noncopyable. Basically, any class
> that is an abstract base class should inherit from abc. abc ensures
> that the destructor is virtual, which is very important for abc's. Is
> there any other 'rule' that applies to abc's that can be put into a
> base utility class like this.
> 
> I know that including a virtual destructor in you class is easy, but
> when defining interfaces or very light classes, it is easily
> overlooked, even though you are fully aware that you are designing a
> abc. A class like this would be an official way to declare an abc.

How would subclassing from this virtual destructor class be any harder
to overlook?

I don't really care for this for several reasons

1) The "Say it in the Code/KISS" principle .  If code is
self-explanatory, don't gush over the details.  For example, the line
   ++count; // increment the count
has a very bad signal-to-noise ratio.  At best, the comment is
unnecessary, at worst, it is counterproductive to understanding since
it draws attention away from more important details.

Subclassing a virtual_destructor class is akin to the superfluous
comment above.  It is a speed bump to be hit in scanning/reviewing a
class.

2) There might be a temptation to add functionality into this base
class.
It would be an all-too-convenient place to dump some functionality that
someone on a team decided that every class needed.  I was on a project
that had a common base class (a la MFC's COBject).  It was a mess.
Eventually the base class became pretty bloated with code for
archiving, logging, synchronization and other things that many classes
did not need.  

3) Learning curve
The first time I see " : public virtual_destructor " in code I will
need to go take a look at the class.  That is lost time.  The fact that
it requires another file is a possible configuration problem.  These
are small problems, but there is little or nothing gained to offset
these dangers.
Good developers have already been conditioned to look for virtual
destructors in a polymorphic base class. If a subclass is used for that
purpose instead, there is an associated learning curve, albeit trivial.
 Inexperienced developers that may not know to look for the virtual
destructor will also not know to look for the inheritance.  And if
there is a choice between learning one of the two methods, I think
anyone would agree that the beginner should learn the standard means.

4) Unneeded complexity
Inheritance, along with templates, overloaded functions, and
namespaces, represents an additional compilation cost, and sometimes a
runtime cost.
I have no problem adding this cost where there is a clear-cut benefit,
but IMO this does not have sufficient benefit to justify the cost.