> I can see some problems with your assumption.  The key one is that
> destructors are often defined inline and once the most-derived class
> destructor is invoked baser-class destructors should be executed as inline
> code.
>

True for small hierarchies. However any serious hierarchy has a virtual
destructor.
This is never generated inline.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Clive Bluston (clive@emultek.co.il) wrote:

: True for small hierarchies. However any serious hierarchy has a virtual
: destructor.
: This is never generated inline.

That is also false.  Virtual destructors and virtual member functions are
called via static binding where the the object is accessed directly rather
than indirectly via a reference or pointer.  Wherever a call to an inline
function is statically bound, it may be generated inline.  This includes
all cases where a derived class destructor invokes a base class
destructor.  If these calls were dynamically bound, the derived class
destructor would loop infinitely by calling itself.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Clive Bluston <clive@emultek.co.il> writes:

> > I can see some problems with your assumption.  The key one is that
> > destructors are often defined inline and once the most-derived class
> > destructor is invoked baser-class destructors should be executed as inline
> > code.
> >
>
> True for small hierarchies. However any serious hierarchy has a virtual
> destructor.
> This is never generated inline.

All hierarchies should have virtual destructors, even small
ones (except perhaps protected dtors). But the destructor can
be inline (I mean virtual inline) even for big hierarchies.

--

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://www.pratique.fr/~bonnardv/
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Clive Bluston (clive@emultek.co.il) wrote:
: I have noticed that many  major software packages written in the past
: year or so take a long time to exit. Even longer if they are managing
: data. Since a lot of disk access occurs during exit I assume that the
: OS is having to swap in a lot of virtual pages.

I can see some problems with your assumption.  The key one is that
destructors are often defined inline and once the most-derived class
destructor is invoked baser-class destructors should be executed as inline
code.

It seems more likely to me that static storage class objects with complex
finalization operations, such as nonempty lists, are giving the kernel a
workout by

  - swapping in the objectss to be destruoyed,
  - accessing their virtual tables (possibly in a different page),
  - calling a virtual destructor (possibly in a different page),
  - deallocating internally-referenced dynamic storage class data
    (guess what goes here).

Depending on the complexity of the object (that is, how many levels of
nested dynamically-allocated objects it contains), this process could be
repeated several times.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

I have noticed that many  major software packages written in the past
year or so take a long time to exit. Even longer if they are managing
data. Since a lot of disk access occurs during exit I assume that the
OS is having to swap in a lot of virtual pages.

It occurred to me that the reason could be as follows:
In any reasonable C++ hierarchy you end up with destructor code
in almost every class. Since programmers try to clean up their memory
when exiting, these destructors get executed. Since it is common
to place the destructor code together with the rest of the class
code, those destructors will be distributed throught the executable
file. So when cleaning up memory we have to page in almost
the whole application.

If this is right, then the situation would probably best be improved
by some compiler/linker support to place all destructor code close
to each other in memory. (this would also improve cache hit
performance). Actually it should improve not just application
exit, but also runtime performance, since destructors in
the same hierachy are always called one after the other.
The same could be done for constructors which have similar
behaviour.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]