Re: static function var not destroyed in Dynamic Library unload
Re: static function var not destroyed in Dynamic Library unload
- Subject: Re: static function var not destroyed in Dynamic Library unload
- From: David Fang <email@hidden>
- Date: Fri, 18 Mar 2005 23:21:13 -0500 (EST)
> It seems that static variable of functions are not destroyed
> when a Dynamic Library is unloaded.
> Only static var of files are.
Hi all,
No responses yet on this? Please correct me if I'm wrong or
elaborate on my answer, for my knowledge may be stale (or just wrong).
The issue here is that the C/C++ standard doesn't specify
precisely when local static objects/variables are destroyed, just that
they are destroyed before the end of the program. Whether or not linkage
is static or dynamic is irrelevant (I think).
> Example:
> Foo& GetFooInstance() {
> static Foo foo;
> return foo;
> }
>
> the Foo destructor is never called.
> but if I do that:
>
> static Foo foo;
> Foo& GetFooInstance() { return foo; }
>
> It works perfectly
> Is that a known bug or am I the only one to have such problem ?
In your first example, the local foo is not destroyed, even during
global static destruction, it is possible that GetFooInstance() may be
called during the global static destruction sequence. Such function-local
static objects conservatively "immortal". It would be bad if the function
was called after foo was destroyed.
In the second example, foo does get destroyed during global static
destruction (in some uncontrolled module ordering). BUT you'd better make
sure that nothing else can possibly reference it through GetFooInstance()
AFTER the module is destroyed. The destruction/clean-up of a module
doesn't prevent other code from calling globally accessible functions.
In a few gcc-versions I've tested such code on, this is the
behavior I observe: that local statics are not destroyed before the end of
global static destruction. Of course, once that's over, all program
memory is released back to the system anyhow.
try googling for:
function local static variable object lifetime
for more on this subject.
May or may not be relevant: In my experience, Foo is often a
user-defined allocator, and GetFooInstance() returns an instance to an
allocator. The way I've designed one type of allocator, If I destroy the
allocator before all of its owned objects are returned to the allocator,
then the allocator will complain. When the objects have the global-static
lifetime with objects and home-allocators across different modules, then
I'd BETTER make sure the allocators outlive their objects, no matter how
the linker decides to order things! (A reference-count acquisition scheme
does the trick.)
David Fang
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden