When does a destructor run...

Discussion in 'C++' started by cgamache@gmail.com, Oct 19, 2005.

  1. Guest

    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.
    , Oct 19, 2005
    #1
    1. Advertising

  2. mlimber Guest

    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-lite/freestore-mgmt.html#faq-16.9

    Cheers! --M
    mlimber, Oct 19, 2005
    #2
    1. Advertising

  3. mlimber wrote:
    > 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-lite/freestore-mgmt.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
    Victor Bazarov, Oct 19, 2005
    #3
  4. Greg Comeau Guest

    In article <>,
    <> 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?
    Greg Comeau, Oct 19, 2005
    #4
  5. Guest

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

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

    -=-

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

    };

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

    MyThing::~MyThing()
    {
    //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
    "deallocation" of the space taken up by the object t. The thing that
    happens right before "deallocation" is the destructor running.

    Maybe I don't understand the word "deallocated" ... Maybe I don't
    understand what happens when an object passes out of scope.
    , Oct 19, 2005
    #5
  6. Howard Guest

    <> wrote in message
    news:...
    > It was a test question, which I got wrong. :) I want to argue the
    > point, and need some expert ammunition. :)
    >
    > When I think "deallocated" I'm talking about what happens to a
    > non-static object when it passes out of scope.
    >
    > -=-
    >
    > class MyThing
    > {
    > public:
    > MyThing();
    > ~MyThing();
    >
    > };
    >
    > MyThing::MyThing()
    > {
    > //blah blah
    > };
    >
    > MyThing::~MyThing()
    > {
    > //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
    > "deallocation" of the space taken up by the object t. The thing that
    > happens right before "deallocation" is the destructor running.
    >
    > Maybe I don't understand the word "deallocated" ... 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 "deallocated", 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
    Howard, Oct 19, 2005
    #6
  7. mlimber Guest

    wrote:
    > It was a test question, which I got wrong. :) I want to argue the
    > point, and need some expert ammunition. :)
    >
    > When I think "deallocated" I'm talking about what happens to a
    > non-static object when it passes out of scope.
    >
    > -=-
    >
    > class MyThing
    > {
    > public:
    > MyThing();
    > ~MyThing();
    >
    > };
    >
    > MyThing::MyThing()
    > {
    > //blah blah
    > };
    >
    > MyThing::~MyThing()
    > {
    > //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
    > "deallocation" of the space taken up by the object t. The thing that
    > happens right before "deallocation" is the destructor running.
    >
    > Maybe I don't understand the word "deallocated" ... 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-lite/dtors.html#faq-11.9
    http://www.parashift.com/c -faq-lite/dtors.html#faq-11.10
    http://www.parashift.com/c -faq-lite/dtors.html#faq-11.14

    Cheers! --M
    mlimber, Oct 19, 2005
    #7
  8. "Greg Comeau" <> wrote in message
    news:dj5rh7$ocf$...
    > In article <>,
    > <> 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. ("immediately 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.
    Louis Newstrom, Oct 20, 2005
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. frs
    Replies:
    20
    Views:
    752
    Alf P. Steinbach
    Sep 21, 2005
  2. arun
    Replies:
    2
    Views:
    541
    benben
    Jun 13, 2006
  3. Jimmy Hartzell
    Replies:
    0
    Views:
    417
    Jimmy Hartzell
    May 19, 2008
  4. Jimmy Hartzell
    Replies:
    2
    Views:
    1,169
    Jimmy Hartzell
    May 20, 2008
  5. KevinSimonson
    Replies:
    7
    Views:
    349
    Screamin Lord Byron
    Oct 18, 2010
Loading...

Share This Page