In looking at the example on p. 238 of Bjarne's new book I've
begun to wonder whether a private destructor *really* absolutely
prevents derivation.

Clearly, explicit and implicit calls of a base class's private
destructor are disallowed.  However, there is no implicit call
of a destructor for an object allocated on the free store except
via delete().

It's my reasoning that such objects can be created on the free store,
but cannot be delete()d, unless destructors are invoked implicitly
for objects on the free store at program termination.  This would be
a change from the rules in section 12.4 of the ARM.

--
Joseph Nathan Hall | Joseph's Law of Interface Design: Never give your users
Software Architect | a choice between the easy way and the right way.
Gorca Systems Inc. |                 joseph@joebloe.maple-shade.nj.us (home)
(on assignment)    | (602) 732-2549 (work)  Joseph_Hall-SC052C@email.mot.com

In article <1994Apr13.021021.24045@sat.mot.com> hall_j@sat.mot.com (Joseph Hall) writes:
> In looking at the example on p. 238 of Bjarne's new book I've
> begun to wonder whether a private destructor *really* absolutely
> prevents derivation.
>
> Clearly, explicit and implicit calls of a base class's private
> destructor are disallowed.  However, there is no implicit call
> of a destructor for an object allocated on the free store except
> via delete().
>
> It's my reasoning that such objects can be created on the free store,
> but cannot be delete()d, unless destructors are invoked implicitly
> for objects on the free store at program termination.  This would be
> a change from the rules in section 12.4 of the ARM.

The C++ compiler cannot know if such a free store object will ever be
deleted so maybe it is wise to disallow construction at compile time in the
first place (rather than to make it a run time error).


 -- marc.

################################################################################
 email  preferred address     marc@offline.be [= me@home]
           aka                marc@offline.UUCP ub4b!offline!marc offline!marc
        if [me@home] fails    mdu@abacus.be [= me@brussels.work]
           or                 mdp@cimad.be  [= me@antwerp.work]
           or (not preferred) mduponch@Belgium.EU.net [= me@EUnet.home]
           or (not preferred) mduponch@ub4b.buug.be [= me@EUnet.home]
 fido   2:292/603.26  Marc.Duponcheel@p26.f603.n292.z2.FidoNet.Org [= me@home]
 bix    mduponcheel   mduponcheel@BIX.com [= me@home]
 (to email me FROM CompuServe use '>INTERNET:marc@offline.be')
################################################################################

hall_j@sat.mot.com (Joseph Hall) writes:

>In looking at the example on p. 238 of Bjarne's new book I've
>begun to wonder whether a private destructor *really* absolutely
>prevents derivation.

>Clearly, explicit and implicit calls of a base class's private
>destructor are disallowed.  However, there is no implicit call
>of a destructor for an object allocated on the free store except
>via delete().

>It's my reasoning that such objects can be created on the free store,
>but cannot be delete()d, unless destructors are invoked implicitly
>for objects on the free store at program termination.  This would be
>a change from the rules in section 12.4 of the ARM.

C++ requires that EVERY class have a destructor, and will generate a
default destructor, if an explicit destructor is not supplied. If the
destructor for the base class is private, but not virtual, you might
be able to get away with declaring a destructor for the derived class,
but never defining it.  If the base class destructor is both inaccessible
and virtual, you will almost surely get an error either in compilation
or in linking.

>>>>> David Sachs <b91926@fsgi01.fnal.gov> writes:

> C++ requires that EVERY class have a destructor, and will generate a
> default destructor, if an explicit destructor is not supplied.

This is not quite correct.  According to 12.5, destructors are only
generated "If a base or a member of a class has a destructor and no
destructor is declared for the class itself".  It goes on to say the "The
NOTATION for explicit call of a destructor may be used for any simple type
name".  That means that you can write ip->int::~int(), but it does not mean
that a default destructor is generated for int.

Jason