Thread: Clarify explicitly calling destructors

  1. #1
    Registered User
    Join Date
    Jul 2012
    Posts
    87

    Clarify explicitly calling destructors

    I was reading Alex Alain's C++ pdf book (recommended buy btw), and the book says compiler will still call destructor even when it is not defined in my own class. I see it as destructor will automatically be called for automatic (aka: local) variabls so within a block so once reached the closing curly braces, and must be called for dynamically allocated variables so using
    Code:
    new
    keyword.

    Is it correct to say automatic variables and parameters too are automatically destroyed b/c they are automatically removed from the stack (which is why beauty of recursion works as it can keep track of each moment of a variable), while pointer variables from the heap and so must explicitly call delete which will invoke the appropriate destructor?

    So if I was to write a class that had no dynamically allocated members, then I don't have to define a destructor, right? The author uses a linked list class so a destructor makes sense, but is it safe to say I don't need to include my own destructor if I don't have any dynamically allocated variables b/c I wouldn't know what to include in it btw.

    e.g.
    Code:
    class Hockey_Player
    {
      public:
         int get_goals();
         void print_stats();
          Hockey_Player();
      private:
           int goals;
           string name;
           int number_of_cup_rings;
    };

  2. #2
    Lurking whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    9,613
    Quote Originally Posted by monkey_c_monkey View Post
    Is it correct to say automatic variables and parameters too are automatically destroyed b/c they are automatically removed from the stack (which is why beauty of recursion works as it can keep track of each moment of a variable), while pointer variables from the heap and so must explicitly call delete which will invoke the appropriate destructor?
    That's right, but you don't know why recursion works. Recursive functions will call themselves before they actually end, so different stack frames are made on top of one another. It's only when the base case is reached that you stop calling the function, and the calls have to finish. As the calls finish, typically the steps are compounded in some way in an earlier function call to produce the result, as each part of the stack is freed.

    So if I was to write a class that had no dynamically allocated members, then I don't have to define a destructor, right? The author uses a linked list class so a destructor makes sense, but is it safe to say I don't need to include my own destructor if I don't have any dynamically allocated variables b/c I wouldn't know what to include in it btw.
    The rule is if all the members of a class have destructors then the compiler will generate a destructor for the class that implicitly calls said destructors. So if all of your members are objects that clean up after themselves, you're set.

    The rules are somewhat different when you learn inheritance. The compiler generated destructor for a base class does not work polymorphically, so you will want to avoid relying on one.

  3. #3
    Registered User
    Join Date
    Apr 2006
    Posts
    2,149
    Quote Originally Posted by monkey_c_monkey View Post
    I was reading Alex Alain's C++ pdf book (recommended buy btw), and the book says compiler will still call destructor even when it is not defined in my own class. I see it as destructor will automatically be called for automatic (aka: local) variabls so within a block so once reached the closing curly braces, and must be called for dynamically allocated variables so using
    Code:
    new
    keyword.

    Is it correct to say automatic variables and parameters too are automatically destroyed b/c they are automatically removed from the stack (which is why beauty of recursion works as it can keep track of each moment of a variable), while pointer variables from the heap and so must explicitly call delete which will invoke the appropriate destructor?
    There's another step to calling delete and also to removing variables from the stack: The memory itself must be freed. This means that the program has to know that it's ok to overwrite the former variables, saving it from using more memory. This is often the more important reason calling delete is important. If your program doesn't call delete and keeps calling new it will eventually run out of memory and crash. It can also run slower due to such "leaks".


    So if I was to write a class that had no dynamically allocated members, then I don't have to define a destructor, right?
    If your class has no dynamically allocated members AND it controls no other resources. Memory is one thing that needs to be "released" when you're done. Many other things that work the same way. But in general no you don't need to write destructor.

    As whiteflags points out, there is another case you want a destructor; when writing a base class used for polymorphism. In that case your base class can be augmented with additional members, and implementing a destructor allows those augmented members to release resources if need be. It'll make more sense when you know what a base class is .
    It is too clear and so it is hard to see.
    A dunce once searched for fire with a lighted lantern.
    Had he known what fire was,
    He could have cooked his rice much sooner.

  4. #4
    Registered User
    Join Date
    Apr 2006
    Posts
    2,149
    Quote Originally Posted by whiteflags View Post
    The rule is if all the members of a class have destructors then the compiler will generate a destructor for the class that implicitly calls said destructors. So if all of your members are objects that clean up after themselves, you're set.
    That's not really true. The members of a class will have their destructor called if they have them, when the outer class destructor is called, but this is done regardless of if the class itself has a destructor. It is possible to explicitly call a destructor on an object, but this is only allowed if you're controlling the construction of the object (ala placement new) or if you reconstruct the object so the destructor can be called automatically as normal on a real object.
    Last edited by King Mir; 07-18-2012 at 10:16 PM.
    It is too clear and so it is hard to see.
    A dunce once searched for fire with a lighted lantern.
    Had he known what fire was,
    He could have cooked his rice much sooner.

  5. #5
    Lurking whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    9,613
    Quote Originally Posted by King Mir View Post
    That's not really true. The members of a class will have their destructor called if they have them, when the outer class destructor is called, but this is done regardless of if the class itself has a destructor.
    Perhaps it is my own opinion, but I find this wording to be confusing. It is one of my biggest gripes that C++ will call special functions that "aren't there". So I understand that the destructor is compiler generated. The only way I could be wrong is if that doesn't happen anymore in modern compilers. I find that awkward if that's true, because in the case of placement new, you'd be calling a function that "isn't there". It's irrelevant since unless you write it, it's invisible to you anyway.

    It is possible to explicitly call a destructor on an object, but this is only allowed if you're controlling the construction of the object (ala placement new) or if you reconstruct the object so the destructor can be called automatically as normal on a real object.
    I never said it wasn't possible.
    Last edited by whiteflags; 07-18-2012 at 11:41 PM.

  6. #6
    Registered User
    Join Date
    Apr 2006
    Posts
    2,149
    Quote Originally Posted by whiteflags View Post
    Perhaps it is my own opinion, but I find this wording to be confusing. It is one of my biggest gripes that C++ will call special functions that "aren't there". So I understand that the destructor is compiler generated. The only way I could be wrong is if that doesn't happen anymore in modern compilers. I find that awkward if that's true, because in the case of placement new, you'd be calling a function that "isn't there". It's irrelevant since unless you write it, it's invisible to you anyway.
    My objection is that your post suggests that if you write a destructor then you have to call the destructors of all the member objects. That's not the case.

    As for calling functions that aren't there, I think the best way to view it is that all objects have distructors, but trivial destructors don't do anything. Obviously a compiler won't actually generate a trivial destructor, but this is part of the many optimizations that the compiler is allowed to do that don't impact the visible impact of a program.
    It is too clear and so it is hard to see.
    A dunce once searched for fire with a lighted lantern.
    Had he known what fire was,
    He could have cooked his rice much sooner.

  7. #7
    Lurking whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    9,613
    Quote Originally Posted by King Mir View Post
    My objection is that your post suggests that if you write a destructor then you have to call the destructors of all the member objects. That's not the case.
    My post says that the calls are implicit:
    The rule is if all the members of a class have destructors then the compiler will generate a destructor for the class that implicitly calls said destructors. So if all of your members are objects that clean up after themselves, you're set.
    If you get from this that when you write a destructor, that you have to explicitly call the destructors of members, I think that is a comprehension problem.
    Last edited by whiteflags; 07-19-2012 at 11:24 AM.

  8. #8
    Registered User
    Join Date
    Apr 2006
    Posts
    2,149
    You're post says that they are implicit if the compiler generates a destructor. They way you're claiming that these implicit calls are part of the destructor suggest that defining an explicit destructor will not generate the "implicit" member destructor calls.

    As I would describe it, the calls to member destructor is not part of the destructor at all. It's something that happens after every destructor call.

    Note that describing it my way requires defining a class that is trivially destructible as one that has a trivially destructor and so do all it's members.
    It is too clear and so it is hard to see.
    A dunce once searched for fire with a lighted lantern.
    Had he known what fire was,
    He could have cooked his rice much sooner.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Can someone clarify what a 'slow event' is.
    By Overworked_PhD in forum Networking/Device Communication
    Replies: 2
    Last Post: 01-13-2008, 05:11 PM
  2. Can someone clarify this comment.
    By Overworked_PhD in forum C Programming
    Replies: 2
    Last Post: 05-15-2007, 10:17 PM
  3. Explicitly calling destructor.
    By anonytmouse in forum C++ Programming
    Replies: 6
    Last Post: 03-11-2004, 01:51 AM
  4. Pls clarify the doubt in pointers...
    By sguruprasanna in forum C Programming
    Replies: 4
    Last Post: 07-23-2002, 05:20 AM
  5. Clarify
    By Mr. Squirrel in forum Windows Programming
    Replies: 0
    Last Post: 12-02-2001, 04:35 PM