Hi All,

I'm considering using static C++ objects in a DLL/.so as a means to
managing and cleaning up resources when the library is dynamically
unloaded.  I believe that this is outside the scope of the C++
standard.  I'm wondering if it is enough of a defacto standard in
implementations that it can be relied upon.

I've run a test on Windows, Solaris 2.6 + 7, Linux glibc 2.2 + 2.3,
HP-UX 11.00, AIX 4.3 and DEC Unix (OSF Tru64) and in all cases got the
behaviour that I wanted -- a global object in the DLL was constructed
when the DLL was loaded and destructed when the DLL was unloaded.

My main reasons for wanting to use this approach is that atexit is
unsafe in a DLL (you can't unregisted atexit handlers, so if the DLL
is unloaded there will most likely be a crash on exit), and DllMain
and the Unix equivalents is no good for a library which could be used
as a DLL, as a static library, or static linked into a higher level
DLL.

Does anyone know how widely this technique would be supported, and/or
have any negative experience with using this approach?

Regards,

Steven

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

"Steven Reddie" <smr@essemer.com.au> wrote in message
news:f93791bd.0408181923.24b66b10@posting.google.com...
 > Hi All,
 >
 > I'm considering using static C++ objects in a DLL/.so as a means to
 > managing and cleaning up resources when the library is dynamically
 > unloaded.  I believe that this is outside the scope of the C++
 > standard.  I'm wondering if it is enough of a defacto standard in
 > implementations that it can be relied upon.
 >
 > I've run a test on Windows, Solaris 2.6 + 7, Linux glibc 2.2 + 2.3,
 > HP-UX 11.00, AIX 4.3 and DEC Unix (OSF Tru64) and in all cases got the
 > behaviour that I wanted -- a global object in the DLL was constructed
 > when the DLL was loaded and destructed when the DLL was unloaded.
 >
 > My main reasons for wanting to use this approach is that atexit is
 > unsafe in a DLL (you can't unregisted atexit handlers, so if the DLL
 > is unloaded there will most likely be a crash on exit), and DllMain
 > and the Unix equivalents is no good for a library which could be used
 > as a DLL, as a static library, or static linked into a higher level
 > DLL.
 >
 > Does anyone know how widely this technique would be supported, and/or
 > have any negative experience with using this approach?

AFAIK, you can rely on it on all modern platform. The worst case I remember
was old versions of HP-UX (I think 10.20) where this was working only if the
main program was C++ and/or using some specific linker flags.

For an OS, a half way decent shared libray implementation needs to have an
init/unload entry point like Win32 DllMain. It is obvious that a C++ linker
generating shared library will use these entry points to generate the
necessay code to call the constructors and destructors of static objects of
the library.

-- 
Fr�d�ric Lachasse - ECP86


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

smr@essemer.com.au (Steven Reddie) writes:

> Hi All,
>
> I'm considering using static C++ objects in a DLL/.so as a means to
> managing and cleaning up resources when the library is dynamically
> unloaded.  I believe that this is outside the scope of the C++
> standard.  I'm wondering if it is enough of a defacto standard in
> implementations that it can be relied upon.
>
> I've run a test on Windows, Solaris 2.6 + 7, Linux glibc 2.2 + 2.3,
> HP-UX 11.00, AIX 4.3 and DEC Unix (OSF Tru64) and in all cases got the
> behaviour that I wanted -- a global object in the DLL was constructed
> when the DLL was loaded and destructed when the DLL was unloaded.

Depending on platform and configuration, gcc registers destructors of
    static objects using either atexit, or __cxa_atexit (see
    http://xrl.us/csjr and http://xrl.us/csju) __cxa_atexit does just
    want the registered functions are called when the shared library
    is unloaded. But functions registered using atexit are called at
    program exit, possibly long after the shared library has been
    unloaded, probably resulting in SIGILL, or somesuch. At my
    current job, our coding guidlines contain a general prohibition
    against static objects with non-trivial destructors in shared
    libraries, precisely becuase it doesn't work on some of the
    platforms we must support.
    
[snip]
> Does anyone know how widely this technique would be supported, and/or
> have any negative experience with using this approach?

It works on typical linuces that have gcc 3.2 or newer (it may work
    with 3.0 or 3.1 - I don't recall.) It does not work on older
    boxen that still have gcc 2.9x . There are probably other
    platforms where it won't work even with recent gcc, because
    __cxa_atexit isn't universal. 


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