Re: [I don't think it's off-topic at all] Linking speed for C++

[Michael Matz <matz at kde dot org>]

Hi,

On Thu, 31 May 2001 Hildo.Biersma@morganstanley.com wrote:

> >>>>> "Michael" == Michael Matz <matz@kde.org> writes:
> Michael> Without further means o would be a program-exit memleak, so
> Michael> we have a template (for type-safety) which collects all such
> Michael> objects in a list, which then is cleaned at program exit.
>
> Why do you store static pointers to objects,

Interesting isn't it?  As with everything, to which there exists a simple
solution, which isn't used, there is a reason, whose goodness is
proportional to the convoluteness of the solution taken instead ;-)

> instead of static objects?

You mean like this:
void f() {
  static Object o;
  ...
}
?  This would work, if we wouldn't talk libraries.  libraries and
dlopen'ed DSO's screw everything.  E.g. on linux (I also saw this on
Solaris) something like the above segfaults in ld.so when it's
dlopen()'ed.  Under special circumstances only.  Sometimes you need more
libraries, sometimes loaded in special patterns, to see this behaviour.
What's interesting is, that file-local static objects (instead of
function-local ones) usually work as expected, but they are constructed at
load time, not at function invocation time.  That's why KDE has a "static
object are evil" approach ;-)

Besides: there are platforms, where static ctors/dtors are not supported
at all (g++ on HP-UX I believe), or for dlopen'ed DSOs.

Ciao,
Michael.