Thread: Destructors

  1. #1
    Registered User
    Join Date
    Oct 2008
    Posts
    115

    Destructors

    As to my understanding before, that, so long as you dynamically requested a memory location from the operating system you have to bring it back using a destructor. I had an assumption since I used C++ that the memory you requested from the operating system is automatically released back to the OS. The book i've read stated that the destructor is not automatically releasing the memory back to the operating system, it's performing termination housekeeping so that the memory can be reused by the objects. I just wanted to be sure to what I understand, let's say you dynamically requested a memory from the operating system and you no longer need it, of course you will have to code a destructor for that. Since it's the destructor's job to free the memory (but not bringing it back to the operating system just yet) the destructor still holds the memory location or size? if so, what if it asks for the another memory location but the memory that the destructor holds ( termination housekeeping ) is not sufficient for that request, it will request to the operating system again? How is it going to release the memory to the OS, when the program terminates?

  2. #2
    Master Apprentice phantomotap's Avatar
    Join Date
    Jan 2008
    Posts
    5,108
    Yikes!

    What book are you reading?

    *sigh*

    I don't even know where to being making corrections. >_<

    Nevermind!

    Plugging "C++ local variables", "C++ stack variables", "C++ freestore", "C++ dynamic memory", and "C++ RAII" into your favorite search engine should straiten you out.

    Soma
    Last edited by phantomotap; 02-18-2009 at 12:42 AM. Reason: >_<

  3. #3
    Registered User
    Join Date
    Oct 2008
    Posts
    115

    Question

    wonder why?

  4. #4
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    28,413
    Do you know what is a destructor?
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  5. #5
    Registered User
    Join Date
    Jun 2005
    Posts
    6,815
    As a rough rule, any resource that is manually allocated by your program should also be released by your program. That's just as true for memory as for any other resource (file handles, system semaphores, mutexes, etc etc).

    Modern operating systems, typically, will clean up memory used by a process as it terminates. However, operating systems are fairly complex, so some things can be done incorrectly. Even if the OS does that right, there are still other resources that are shared between programs - if you intend that those resources be released when your program exits, you cannot rely on the OS to do it for you.

    There are also some less modern operating systems (eg MS-DOS) that do not release memory used by programs cleanly. Those older systems are still in use. And, of course, there are embedded systems that run without an operating system but use a simpler bootstrapping process - and those systems will not clean up memory usage.

    As to whether you need to do this using destructors: you don't. The key is ensuring resources are released, and not relying on some operating system magic to ensure that. The use of constructors (to allocate) and destructors (to deallocate) - eg RAII - is a technique that can help with resource management. But there are other techniques.

  6. #6
    Registered User
    Join Date
    Oct 2008
    Posts
    115
    Quote Originally Posted by laserlight View Post
    Do you know what is a destructor?
    dynamically requested a memory location from the operating system you have to bring it back using a destructor. If you're using a constructor you allocate memory then destrucdtor deallocates memory that was used by the objects or any other objects that dynamically requested a memory from the OS.

  7. #7
    verbose cat
    Join Date
    Jun 2003
    Posts
    209
    A class's destructor can be used to free any memory that the class allocated (using the delete keyword), and it can do lots of other things as well. But to understand what a destructor actually is you need to back up a little bit. Plugging the search terms into Google that phantomotap suggested below would be a good place to start.

    In a nutshell, a destructor is a class object's "cleanup function". It is usually a good idea to have the destructor free memory that was allocated inside the class object, but the destructor can do anything else that is needed to clean up after the object.

    It sounds to me like you aren't asking about destructors however, rather you are asking about "how to return memory you requested from the operating system". If so, then you should be looking into delete, not destructors.

    Whenever you use the new keyword to allocate memory, you should at some point in your program use delete (or delete[]) to de-allocate that memory. It's as simple as that. There is also the malloc()/free() pair of memory functions, but in C++ you aren't likely to use them unless you are doing your own memory management.

    Under the hood your program is doing memory bookkeeping that you the programmer don't have to get involved with unless you need more control over the memory management. When you call new, your program might ask the OS for additional memory if it doesn't already have enough. Later when you call delete, your program marks the memory as no longer used and it might be reclaimed by the OS, or it might not.

    You can call delete anywhere in your program that it makes sense to do so, whether it is in a class's destructor, or in some other function that you manually call from somewhere else. Indeed there have been books written about memory management and when to use new and delete properly.
    abachler: "A great programmer never stops optimizing a piece of code until it consists of nothing but preprocessor directives and comments "

  8. #8
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,318
    Quote Originally Posted by $l4xklynx View Post
    let's say you dynamically requested a memory from the operating system and you no longer need it, of course you will have to code a destructor for that. Since it's the destructor's job to free the memory (but not bringing it back to the operating system just yet) the destructor still holds the memory location or size?
    A destructor does not free the memory of the object being destructed. That is one of the jobs of the delete keyword.
    My homepage
    Advice: Take only as directed - If symptoms persist, please see your debugger

    Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

  9. #9
    Registered User
    Join Date
    Oct 2008
    Posts
    115
    Quote Originally Posted by iMalc View Post
    A destructor does not free the memory of the object being destructed. That is one of the jobs of the delete keyword.
    I'm sorry for not being clear with my statement, I understand that when you allocate memory using new or new[] you use the delete or delete[] for deallocation and it is placed in a destructor.


    I was just confused with this sentence that I read in one of the book I bought: The book i've read stated that the destructor is not automatically releasing the memory back to the operating system, it's performing termination housekeeping so that the memory can be reused by the objects.

  10. #10
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,318
    Quote Originally Posted by $l4xklynx View Post
    I'm sorry for not being clear with my statement, I understand that when you allocate memory using new or new[] you use the delete or delete[] for deallocation and it is placed in a destructor.


    I was just confused with this sentence that I read in one of the book I bought: The book i've read stated that the destructor is not automatically releasing the memory back to the operating system, it's performing termination housekeeping so that the memory can be reused by the objects.
    "placed in" is what does not make sense there. delete / delete[] first calls the destructor, but there's nothing special about a destructor except that it is called automatically. Other than that, it's pretty much just like a regular function. After calling the destructor, delete then actually frees the memory. Think of a destructor like a callback function that gets called whenever the object is about to be deallocated. It's that object's last chance to do anything, e.g. releasing it's own members. (That's what one could loosely call "termination housekeeping")
    My homepage
    Advice: Take only as directed - If symptoms persist, please see your debugger

    Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

  11. #11
    Registered User
    Join Date
    Feb 2003
    Posts
    596
    By "placed in a destructor", $l4xklynx, I think you referring to an object like a linked list, or other data structure which may dynamically allocate memory (for example, to add nodes) in addition to the memory occupied by the class object itself. For example, a List object itself may consist of only a pointer or two, and maybe some auxiliary variables holding information about the list (e.g., length). The List object contains no nodes, only pointers to nodes. When nodes are added to the list, generally the only pointers to those nodes are the pointers in the List object, or pointers in other nodes which belong to the list.

    The default destructor for the List will release only the memory that belongs to the List object itself -- its own pointers and auxiliary variables. It does nothing about the memory that belongs to the nodes, and once the List's pointers are gone those nodes will be inaccessible and the memory they occupy remains unusable.

    So in this situation, you explicitly write a destructor containing code to step through the list and delete each node one at a time.

    But the point about "releasing the memory back to the operating system" vs. letting the memory be "reused by the objects" is less clear. Probably that book is trying to distinguish between objects allocated on the program's stack (this would be any objects created when the program is initally loaded), and objects allocated on the heap (dynamically allocated during runtime). If I'm not mistaken, the memory that was allocated on the stack would still belong to the program as long as the program continues to run, but memory that was allocated on the heap is returned to the operating system and can be reallocated by the OS to another process even while the first program is still running. Returning to the List example, if you write a destructor that steps through the list to delete its nodes, and your program contains a block of code which creates a List object:
    Code:
     ... // other code
    {List my_list;
    my_list.add_node( ); // List::add_node() dynamically allocates memory to create a Node
    ... // bla bla bla
    }
    ... // more code
    at the end of that block {} your destructor for my_list will be called. It will delete the Node object and makes its memory available to the OS. The memory that was allocated to the List object my_list still belongs to the program and can't be reused by the OS while the program is still running, but since my_list goes out of scope at the end of the {} block, that memory is also no longer usable by the program.

    Of course, I may be wrong. If so, someone please correct me.

  12. #12
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    The idea is that an object (an instantiated class) is self-sustaining. The programmer creates an object of it, uses it, and throws it away when not needed. Everything the object needs to function is usually created and acquired during the constructor. Similarly, anything the class acquired during its lifetime is released again in the destructor. The destructor is called when the object is destroyed.

    Now, that is not to say that delete ([]) needs to be placed in a destructor. It can appear anywhere in code. It is just that if you use new ([]) in the constructor, you most likely want a delete ([]) in the destructor to release that memory.
    And as far as resource management goes, as far as C++ is concerned, new acquires memory and delete frees the memory. Nothing less, nothing more. Now, if that memory is actually left in the program or "rescheduled" to other processes or whatever is up to the operating system and C++ does not care.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  13. #13
    Registered User
    Join Date
    Oct 2008
    Posts
    115
    Now I clearly understand the process. How could this book provide such information that is not as clear as to what you people are saying ( I think there is a big discrepancy) . Anyway, it's a good thing that I don't only rely on one book and what the book is saying.

  14. #14
    Registered User
    Join Date
    Feb 2003
    Posts
    596
    Quote Originally Posted by $l4xklynx View Post
    Now I clearly understand the process. How could this book provide such information that is not as clear as to what you people are saying ( I think there is a big discrepancy) . Anyway, it's a good thing that I don't only rely on one book and what the book is saying.
    If this is the first book you have ever read that gives unclear or erroneous information, you are very lucky indeed. But it won't be the last one.

  15. #15
    Registered User
    Join Date
    Oct 2008
    Posts
    115
    Quote Originally Posted by R.Stiltskin View Post
    If this is the first book you have ever read that gives unclear or erroneous information, you are very lucky indeed. But it won't be the last one.
    I feel like I'm wasting money for just a book that provides wrong information. Any good books that you could provide?

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Can a class have multiple destructors?
    By meili100 in forum C++ Programming
    Replies: 1
    Last Post: 05-14-2008, 05:28 PM
  2. Destructors in STL?
    By sawer in forum C++ Programming
    Replies: 4
    Last Post: 08-09-2006, 09:35 AM
  3. I always have memory errors in destructors
    By rmullen3 in forum C++ Programming
    Replies: 2
    Last Post: 01-03-2004, 03:07 PM
  4. Destructors in dynamically allocated arrays
    By frenchfry164 in forum C++ Programming
    Replies: 1
    Last Post: 11-28-2003, 11:26 PM
  5. Virtual & Pure virtual destructors
    By BMJ in forum C++ Programming
    Replies: 61
    Last Post: 08-22-2002, 09:38 AM