Re: Polymorphic delete and iterators

Sideswipe wrote:


That's definitly a problem. The rule is that if you delete an
object, either the pointer has the same type as the dynamic type
of the object, or the destructor is virtual, or you have
undefined behavior. You're in the last case.

What actually happens, of course, is that the compiler uses the
virtuality of the destructor as the signal that it must do some
special calculations to get the actual address (and even to
determine which operator delete function to use---but that's an
advanced issue). The usual implementation is for the compiler
to actually generate the call to the deallocation functions in
the destructor, with some sort of hidden flag to indicate
whether it should be called or not. And of course, this only
works if there is dynamic dispatch on the destructor.

There are no other constraints on the destructor, and in
"interfaces", I generally provide it directly inline, since it
is the only function which has a definition, and I don't really
want to create a source file just for it.


This is typically the case if you use multiple or virtual
inheritance in anyway.


Converting a pointer to derived to a pointer to base may modify
the physical address. Using a virtual destructor is C++'s way
of telling the compiler that it has to redo the conversion, in
reverse, in a delete statement.

Note that it's also important if any of the derived objects has
something to do in the destructor, e.g. if the derived object
contains an element of type string. You do want the destructor
of the derived object to be called. But this is, in a certain
sense secondary, since you need the virtual destructor even if
you don't have anything to do in the derived class.


To nothing good. That's why they're called dangling pointers.
The are not null, so you cannot test for them, but anything you
do with them is undefined behavior. Formally, that includes
even just copying them. And, technically speaking, even just
having them in a standard container.

A 100% guaranteed correct implementation of your loop would look
something like:

     for ( map< Key, MyObject* >::iterator itr = objects.begin() ;
             itr != objects.end() ;
             itr ++ ) {
         MyObject* tmp = itr->second ;
         itr->second = NULL ;
         delete tmp ;
     }

IF this is the very last thing you are doing, prior to
destructing the map, I would'nt worry too much about it---it's
one of those undefined behaviors which in fact work everywhere,
and that no implementation would dare break because so many
users are using it. But if the map will continue to exist,
after the loop, I would definitly either set the pointers to
NULL, or remove the elements from the map, in order to avoid
future problems. (If you start removing elements from the map,
pay attention to the validity of iterators. Removing an element
under an iterator invalidates the iterator, so you need to do
something like:

     map< Key, MyObject* >::iterator itr = objects.begin() ;
     while ( itr != objects.end() ) {
         itr = objects.erase( itr ) ;
     }

or:

     map< Key, MyObject* >::iterator itr = objects.begin() ;
     while ( itr != objects.end() ) {
         objects.erase( itr ++ ) ;
     }

--
James Kanze (Gabi Software) email: james.kanze@gmail.com
Conseils en informatique orient?e objet/
                    Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34

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