Re: virtual fn, destructor
On Dec 14, 7:13 pm, zr <zvir...@gmail.com> wrote:
On Dec 14, 7:03 pm, SG <s.gesem...@gmail.com> wrote:
On 14 Dez., 13:31, zr <zvir...@gmail.com> wrote:
On Dec 12, 11:41 am, James Kanze <james.ka...@gmail.com> wrote:
Actually, the usual rule is that the base class
destructor must be either virtual or protected. And of
course, it is a "programming standards" rule, not
something imposed by the standard.
[...]
I may have either misunderstood you or do not understand
how STL containers work, but don't STL containers call
their stored objects` destructors? Doesn't this require
the destructors to be public?
Objects in a standard container must have publically accessible
destructors, yes. They also must be copiable and assignable: in
sum, they must have value semantics. Which means that they
almost certainly aren't polymorphic.
Yes. The point of having protected destructors is to disable
deleting objects through base class pointers and to avoid
slicing.
class A {
protected:
A~() {}
};
class B : public A {};
B q; // OK, B::~B() is public
B* y = new B;
A x = *y; // ill-formed
A* p = y; // OK, *y is an A
delete p; // ill-formed
You can still create a vector<B> object.
In what cases would deleting the derived using a base pointer
is undesirable? Is there any convincing example?
Objects derived from std::iterator. Just about any time, in
fact, where inheritance is not being used for polymorphism.
Cases where there are pre-conditions on destruction. (This is
often the case for entity objects.) Client code doesn't delete;
it calls a member function, which validates the pre-conditions
before deleting the object. Or more generally, cases where the
lifetime is managed by the object itself.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34