When does a destructor run...

[cgamache]

Which is a more correct statement?

A destructor runs automatically when an object is deallocated.

or

A destructor runs automatically immediately before an object is
deallocated.

[mlimber]

cgama...@gmail. com wrote:

Which is a more correct statement?

A destructor runs automatically when an object is deallocated.

or

A destructor runs automatically immediately before an object is
deallocated.

I don't see a contradiction between them. The second provides more
information, however. Compare this FAQ:

http://www.parashift.com/c++-faq-lit....html#faq-16.9

Cheers! --M

[Victor Bazarov]

mlimber wrote:

cgama...@gmail. com wrote:

Which is a more correct statement?
First of all, you need to specify that you're talking about dynamic or
automatic objects. Statics may never have their storage deallocated.
A destructor runs automatically when an object is deallocated.

or

A destructor runs automatically immediately before an object is
deallocated .

I don't see a contradiction between them. The second provides more
information, however. Compare this FAQ:

http://www.parashift.com/c++-faq-lit....html#faq-16.9

The destructor can also be called explicitly. But regardless of that,
after the destructor has been called, there is no more "object", so to
be entirely semantically correct, the second statement is a bit wrong
saying "an object is deallocated". The storage is deallocated, not the
object.

V

[Greg Comeau]

In article <11************ **********@g14g 2000cwa.googleg roups.com>,
<cg******@gmail .com> wrote:

Which is a more correct statement?

A destructor runs automatically when an object is deallocated.

or

A destructor runs automatically immediately before an object is
deallocated.

I don't like the choices, but if had to choice faced
with life or death, would go with choice 1.
That said, I'll bet that you probably have some other underlying
thought to ask?
--
Greg Comeau / Celebrating 20 years of Comeauity!
Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout
World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90.
Comeau C/C++ with Dinkumware's Libraries... Have you tried it?

[cgamache]

It was a test question, which I got wrong. :) I want to argue the
point, and need some expert ammunition. :)

When I think "deallocate d" I'm talking about what happens to a
non-static object when it passes out of scope.

-=-

class MyThing
{
public:
MyThing();
~MyThing();

};

MyThing::MyThin g()
{
//blah blah
};

MyThing::~MyThi ng()
{
//destruct destruct
};

void Func()
{
MyThing t;
}

int main()
{

Func();
return 0;

}

-=-

Here how I imagine things happening: in Func, MyThing is "allocated"
and the constructor runs. When Func is over, MyThing passes out of
scope ... First the destructor runs, to take care of anything that the
programmer needs taken care of. The last thing to happen is
"deallocati on" of the space taken up by the object t. The thing that
happens right before "deallocati on" is the destructor running.

Maybe I don't understand the word "deallocate d" ... Maybe I don't
understand what happens when an object passes out of scope.

[Howard]

<cg******@gmail .com> wrote in message
news:11******** **************@ f14g2000cwb.goo glegroups.com.. .

It was a test question, which I got wrong. :) I want to argue the
point, and need some expert ammunition. :)

When I think "deallocate d" I'm talking about what happens to a
non-static object when it passes out of scope.

-=-

class MyThing
{
public:
MyThing();
~MyThing();

};

MyThing::MyThin g()
{
//blah blah
};

MyThing::~MyThi ng()
{
//destruct destruct
};

void Func()
{
MyThing t;
}

int main()
{

Func();
return 0;

}

-=-

Here how I imagine things happening: in Func, MyThing is "allocated"
and the constructor runs. When Func is over, MyThing passes out of
scope ... First the destructor runs, to take care of anything that the
programmer needs taken care of. The last thing to happen is
"deallocati on" of the space taken up by the object t. The thing that
happens right before "deallocati on" is the destructor running.

Maybe I don't understand the word "deallocate d" ... Maybe I don't
understand what happens when an object passes out of scope.

You've got the right idea. But it's not the object itself (e.g., MyThing)
being "deallocate d", but rather the storage (memory) for it. But your
ordering is correct. The constructor is called after memory is allocated
for an object, and the destructor is called before that memory is released.

If you're going to argue the point with your instructor, then you need to
ask exactly what he meant by the phrase "object is deallocated". If he just
meant "when an object goes out of scope" or "when delete is called on a
pointer", then answer #1 would be correct enough, since that is when the
destructor gets called. But if he meant "when the storage for the object is
released", then answer #2 is more correct.

Basically, I'd say that the question is poorly worded in the first place.

-Howard

[mlimber]

cg******@gmail. com wrote:

It was a test question, which I got wrong. :) I want to argue the
point, and need some expert ammunition. :)

When I think "deallocate d" I'm talking about what happens to a
non-static object when it passes out of scope.

-=-

class MyThing
{
public:
MyThing();
~MyThing();

};

MyThing::MyThin g()
{
//blah blah
};

MyThing::~MyThi ng()
{
//destruct destruct
};

void Func()
{
MyThing t;
}

int main()
{

Func();
return 0;

}

-=-

Here how I imagine things happening: in Func, MyThing is "allocated"
and the constructor runs. When Func is over, MyThing passes out of
scope ... First the destructor runs, to take care of anything that the
programmer needs taken care of. The last thing to happen is
"deallocati on" of the space taken up by the object t. The thing that
happens right before "deallocati on" is the destructor running.

Maybe I don't understand the word "deallocate d" ... Maybe I don't
understand what happens when an object passes out of scope.

Your summary is accurate. Deallocation -- whether from the stack for
automatic objects or for dynamically allocated objects from some other
pool of memory (like the one manipulated by malloc/free or one
associated with a custom allocator, e.g., for a system with segmented
memory) -- is the process of making a block of memory available for
reallocation. Destruction is simply the invocation of destructors,
which must happen before the memory in which the object resides is
deallocated.

In C++, when an automatic object goes out of scope (at the end of its
block or when an exception is thrown), the object is destructed and
then the memory in which it resided is deallocated. Of course, if the
object itself had any other memory for which it was responsible --
whether allocated in the constructor, member functions, or by direct,
external manipulation of its members -- that should also be destructed
and deallocated. std::auto_ptr and other such constructs help manage
this process.

Compare the FAQs on "placement new" for more what goes on behind the
scenes in object instantiation and destruction since essentially the
same thing happens for objects allocated on the stack like "t" in
Func() above:

http://www.parashift.com/c++-faq-lit....html#faq-11.9
http://www.parashift.com/c++-faq-lit...html#faq-11.10
http://www.parashift.com/c++-faq-lit...html#faq-11.14

Cheers! --M

[Louis Newstrom]

"Greg Comeau" <co****@panix.c om> wrote in message
news:dj******** **@panix3.panix .com...

In article <11************ **********@g14g 2000cwa.googleg roups.com>,
<cg******@gmail .com> wrote:

Which is a more correct statement?

A destructor runs automatically when an object is deallocated.

or

A destructor runs automatically immediately before an object is
deallocated .

I would say the second is more correct. ("immediatel y before an object is
deallocated")

My main reasoning here, is that the members of the object still exist, and
can be referenced within the destructor. After the destructor is called,
then the memory is de-allocated.