From: Francis Glassborow on
In article <b5f29$45eeaedb$1860878d$6215(a)KNOLOGY.NET>, "Dennis (Icarus)"
<ala_dir_diver(a)yahoo.com> writes
>"Val" <valosmith(a)gmail.com> wrote in message
>news:1173196295.237848.323320(a)s48g2000cws.googlegroups.com...
>>
>> This is talked about in detail in Item 14 of "Effective C++" by
>> Meyers.
>>
>> You can't have a pure virtual destructor if the compiler is following
>> the language spec. If you were to derive a concrete class from the
>> abstract one, then create and destroy an object, the base class's
>> destructor would be invoked immediately before the derived
>> destructor. If the base destructor isn't implemented, then this is a
>> problem.
>
>I thought that destructors of derived classes were invoked before those of
>base classes?
They are, but destructors automatically chain. When the body of a dtor
completes its final act is to 'call' the dtor of the base(s)

Val got it the wrong way round, however there must be an implementation
of every explicit dtor.


--
Francis Glassborow ACCU
Author of 'You Can Do It!' and "You Can Program in C++"
see http://www.spellen.org/youcandoit
For project ideas and contributions:
http://www.spellen.org/youcandoit/projects


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: norbert.riedlin on
> > No, making a function a pure virtual does not prevent you from
> > implementing it. All it does is to require that ever derived concrete
> > class has an implementation (possibly inherited from an intermediate
> > derived class)
>
> That's right, but maybe a bit confusing. What it means is that
> until at least one class on a direct path from the most derived
> class to the base class has a user declared (and defined)
> destructor, the class is abstract, and cannot be instantiated.
> What declaring the destructor pure virtual does, in practice, is
> to require every derived class to provide a user defined
> destructor, even when it wouldn't need one otherwise.

Hi,

is that true? I mean, every class not declaring a destructor, declares
and defines it implicitly. And that should also be the case with a
class deriving from a class declaring a pure virtual destructor, isn't
it? The following code compiles fine with gcc version 4.0.2 and
comeau's online compiler and seems to support my guess:

<code>

struct test1 {
public:
virtual ~test1()=0;
};
test1::~test1()
{}

struct test2:test1 {
};

test2 t2;

</code>

Does anyone know what the standard has to say in this regard?

Bye
Norbert


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: red floyd on
norbert.riedlin(a)web.de wrote:
>
> <code>
>
> struct test1 {
> public:
> virtual ~test1()=0;
> };
> test1::~test1()
> {}
>
> struct test2:test1 {
> };
>
> test2 t2;
>
> </code>
>
> Does anyone know what the standard has to say in this regard?
>

That code is perfectly fine, and exactly what you need to do.

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Sebastian Redl on


On Thu, 8 Mar 2007, norbert.riedlin(a)web.de wrote:

> >
> > What declaring the destructor pure virtual does, in practice, is
> > to require every derived class to provide a user defined
> > destructor, even when it wouldn't need one otherwise.
>
> Hi,
>
> is that true? I mean, every class not declaring a destructor, declares
> and defines it implicitly. And that should also be the case with a
> class deriving from a class declaring a pure virtual destructor, isn't
> it?
>
> Does anyone know what the standard has to say in this regard?
>

Not much. 12.4 talks about destructors. Paragraph 3 is about the implicit
declaration, paragraph 5 about the implicit definition. Paragraph 7 says
that destructors can be virtual and even pure virtual, and that if the
destructor of any base class is virtual, that of the derived class is too,
whether implicit or user-defined.
10.4 talks about abstract classes; however, no special mention of
destructors is made.
10.3 talks about virtual functions in general. Paragraph 4 in particular
mentions that derived destructors override base destructors.

It seems that the standard does not differ between implicit and explicit
destructors in general, so I would say you are correct: an implicit
destructor is a valid override for a pure virtual destructor and the class
therefore instantiable.

Sebastian Redl

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Gerhard Menzl on
peter koch larsen wrote:

> So if I understand you correctly, you use the virtual destructor as a
> hint that other functions are virtual with a "questionable" default
> implementation? This is silly. If anything, this behaviour requires an
> implicit understanding which should be given in a better way than by
> requiring the implementor to write an empty destructor.

Let me expand a concrete example I have given in another posting. Think
of the GoF state pattern and a state machine with seven states and
twenty requests. The greater part of the cells in the resulting matrix
of 140 handlers is empty, i.e. most states react on a few selected
stimuli (but each state on a different set of them) and do nothing when
receiving the others.

Now which is the sillier way to implement this: insisting on the mantra
that pure virtual destructors are useless, make the base class handlers
pure virtual, and force derived classes to implement several dozens of
empty functions in total, or implement 21 no-ops (20 handlers and one
pure virtual destructor) once in the base class and make derived classes
react only to those requests that they actually need to handle?

You could still argue that writing all those empty overrides is
justified for reasons of documentation, maintainability, locality of
reference, symmetry, consistency, beauty and whatnot. But your argument
of avoiding gratuitous typing just does not hold.

As I said, this is not exactly an everyday scenario, at least for most
problem domains, but when you encounter it (it happened to me once or
twice), you are glad that C++ doesn't get in your way like certain
languages the designers of which were so confident of their prescience
that they banned every feature (or combination of features) they were
certain nobody would or, for that matter, should need.

--
Gerhard Menzl

Non-spammers may respond to my email address, which is composed of my
full name, separated by a dot, followed by at, followed by "fwz",
followed by a dot, followed by "aero".



[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]