question about object destruction

[johny smith]

Suppose there is a policy that all objects are statically declared.

For example:

static Car car();

Then, is there a reason to have a destructor defined for the class Car.

It would seem that perhaps there would not be a need for a destructor
because the object would never go out of scope due to the static storage.

Any insight?

Many thanks

 

[David Harmon]

On Sun, 9 May 2004 16:33:57 -0600 in comp.lang.c++, "johny smith"

Suppose there is a policy that all objects are statically declared.

For example:

static Car car();

That's not an object. It's a forward declaration of a function with no
arguments returning Car.

It would seem that perhaps there would not be a need for a destructor
because the object would never go out of scope due to the static storage.

Static objects are destructed at the end of execution. If you are doing
nothing special, then the default compiler generated destructor may be
all you need.

 

[Juergen Heinzl]

Suppose there is a policy that all objects are statically declared.

For example:

static Car car();

Then, is there a reason to have a destructor defined for the class Car. [-]
Sometimes.

It would seem that perhaps there would not be a need for a destructor
because the object would never go out of scope due to the static storage.

[-]
class static_shm_pointer {
public :
static_shm_pointer( size_t shm_size ) {
/*
** get shared memory
*/
}

~static_shm_pointer() {
/*
** remove shared memory
*/
}
};

void function() {
/*
** time consuming, so do it just once
*/
static static_shm_ptr( 1234 );
}

Cheers,
Juergen

 

[John Harrison]

Suppose there is a policy that all objects are statically declared.

For example:

static Car car();

static Car car;

Then, is there a reason to have a destructor defined for the class Car.

It would seem that perhaps there would not be a need for a destructor
because the object would never go out of scope due to the static storage.

Any insight?

Sometimes the operating system doesn't not automatically recover resources
not released by the program. For instance it might be that if a file is
opened and not closed by a program, then the file will remain open (and
perhaps therefore unusable by any other program) even though the program
that opened the file has exitted.

So in the case of an object which opened a file you would still need a
destructor to close the file.

It's true that most operating systems will recover all the memory used by a
program, but this isn't guaranteed either so its still sensible to have a
destructor.

Finally even if you aren't concerned about the above, its not normally good
design to build into an object the assumtpion that it must be allocated
statically.

john

 

[Andrey Tarasevich]

...
It would seem that perhaps there would not be a need for a destructor
because the object would never go out of scope due to the static storage.
...

I has nothing to do with object's scope, but it has everything to do
with object's lifetime. Destructor is called when object's lifetime
ends. Every object's lifetime ends sooner or later, including objects
with static storage duration. In case of objects with static storage
duration the lifetime ends at the end of the program. That's when the
destructors for such objects are called. I don't see why you'd say that
there's no need for them.