Concerning delete/delete[] at program exit

This is a discussion on Concerning delete/delete[] at program exit within the C++ Programming forums, part of the General Programming Boards category; It's not ridiculous. Do you think the OS cleans up after the application so that applications shouldn't need to clean ...

  1. #31
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,768
    It's not ridiculous. Do you think the OS cleans up after the application so that applications shouldn't need to clean up themselves or to guarantee the stability of the OS? I think the later.
    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.

  2. #32
    and the hat of wrongness Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    32,659
    > This idea was not invented in 1995.
    No, that's when MS finally got around to using it in one of their OS offerings. It has been around for at least 20 years on other operating systems.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.
    I support http://www.ukip.org/ as the first necessary step to a free Europe.

  3. #33
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,248
    Quote Originally Posted by Elysia View Post
    It's not ridiculous. Do you think the OS cleans up after the application so that applications shouldn't need to clean up themselves or to guarantee the stability of the OS? I think the later.
    The latter certainly, the former somewhat. Not having to worry about explicitly releasing every page back to the OS is a step forward in simplicity as well as robustness. At a low level this is valuable from an application standpoint (for instance the implementation of malloc doesn't have to worry about re-brking the heap -- and for that matter how DOES a user application "free the stack" anyway?). As I already said, at the C++ level it is mostly irrelevant, since merely reclaiming memory doesn't cause destructors to run, and not having destructors run is simply incorrect.
    Last edited by brewbuck; 01-05-2008 at 12:07 PM.

  4. #34
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,308
    Quote Originally Posted by robwhit View Post
    I agree with Elysia, cpjust, and iMalc. Except for the release optimization thing. I expect a well-written program to clean up after itself.
    Actually I don't agree with myself there either. I was just seeing what other's might say. I would only do that as a hack, if I was very pressed for time.

    To me, I don't see the issue being so much about freeing memory. Freeing memory doesn't take very long, and if it does you're already doing something wrong in how it is allocated in the first place (e.g. too many tiny non-pooled allocations). If destructors take a while to run then it is perhaps related to other work such as deleting temporary files, or notifying other PCs across the network about the program closing.

    Sometimes you just have to have your destructors run as they may do necessary things like removing hooks too. Due to the way objects are members of larger objects which themselves might be in a list of other objects blah blah etc it often isn't practical to find only exactly what destructors must be run and somehow run those. For those properly using RAII, it can be far easier to simply destroy everything.
    That way things that absolutely have to run at program close can be added anywhere to your program.

    I don't think anyone can use the slow program closing argument without profiling to see where the time really is being spent. There's also restoring monitor modes and re-drawing the desktop, paging other programs back into memory etc, that is going to take some unavoidable time anyway even after your program closes.
    Last edited by iMalc; 01-05-2008 at 01:08 PM.
    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"

  5. #35
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    Elysia, I don't think calling it a 'patch' is really correct. Everything since the 386 (using the Intel line as an example) has had Protected Memory mode built into the CPU, which allows 32-bit OS's to allocate a completely separate virtual memory space to each application. Unlike the Win 3.1 days when a GPF could crash all 16-bit programs that were running, and IPF in 32-bit Windows would only crash the program that caused the IPF. Since Intel provided Windows with a tool to protect separate memory namespaces, they decided to use it. This isn't a patch, it's a new feature that was virtually impossible in earlier CPUs.

  6. #36
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,768
    Whatever you want to call it - it's there to protect the stability of applications (and the OS), not to clean up an application's mess.
    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.

  7. #37
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,248
    Quote Originally Posted by Elysia View Post
    Whatever you want to call it - it's there to protect the stability of applications (and the OS), not to clean up an application's mess.
    Are you suggesting that there is some way of maintaining stability WITHOUT cleaning up messes?

  8. #38
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,768
    No, what I mean is that applications should not rely on the OS to clean up their mess. They should explicitly get rid of resources they acquired.
    The OS is there to safeguard for poorly written application (why should WE have to suffer because some programmers messed up when creating a program?) AND to make sure that if a program crashes or dies in some horrible way, it doesn't up the memory and never release it back to the OS - no, it should ensure stability.
    Yes. It should clean up application's messes if needs be to protect stability and to protect us from applications, but it wasn't built intensionally for cleaning up the mess of a program - only to protect stability and such.
    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.

  9. #39
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,248
    Quote Originally Posted by Elysia View Post
    No, what I mean is that applications should not rely on the OS to clean up their mess. They should explicitly get rid of resources they acquired.
    Except that what you're talking about isn't even possible. Many modern operating systems won't even ALLOW you to give memory back to the OS once you've acquired it. Your program's data size can grow but not shrink.

    So how is a user application supposed to release all resources if it's not even possible?

    Again, this is different from destructing objects. Freeing memory is only a part of that picture.

  10. #40
    Registered User
    Join Date
    Apr 2006
    Posts
    2,050
    Quote Originally Posted by Elysia View Post
    No, I disagree. Even if programs take time to close down, they can do so in the background.
    So you're saying it would not be safe? I think most people here seem to disagree. If it is safe then it is a benefit. Sure, there is a trade off involved, but Sometimes optimization does win over style.

    How so?
    I don't see how it matters if the OS or the app cleans up memory in case of a crash--it's the same.
    (And here's another side argument for a later time - a lot of applications actually save settings upon exit, making you lose everything if they crash, which I find very annoying; me, on the other hand, save settings as soon as they're made!)
    If one of the features of an application you are developing is the ability to safely suddenly terminate at any time, then it is safe to call exit() at any time to force such a termination. Since the feature is there, one may as well use it to quickly close the application. It's fast and guaranteed to work.

    There is no gain to the optimization of letting the OS do the work (the app is exiting, so the user doesn't have to interact with it anymore!) and it's more error-prone too.
    There is a definite optimization.

    The OS just has to flip a switch to mark the memory free.

    Closing the normal way requires stack unwinding (sometimes); destructor calls; calls to free()*, which have to make the memory available to malloc() again, even though the program is shutting down; and only then does the application quit. Then the OS still has to flip the exact same switch to mark the memory free. (Note free() does not generally return memory back to the OS)

    *I'm assuming for simplicity that new/delete are implemented in terms of malloc/free. If they are implemented differently, the functionality would still have to be similar, so it doesn't really matter that it goes by a different name.
    And those are big downsides. ...
    And hey... what if the program DOES require interaction when it quits? Bye-bye to the OS patch-up instead of the program.
    Agreed here. There are many cases where this optimization would not be suitable.

    I'd be willing to consider an argument saying that the optimization is negligible, particularly if evidence was provided. But your argument seems to be most based mostly on stylistic grounds, which take a back seat once optimization kicks in.
    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.

  11. #41
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    I'd say that not calling delete on exit is an optimization hack that should be used very carefully and should be explicitly documented if done.
    The only things that should ever be allowed to be freed by the OS instead of using delete are primitive data types or objects which you have total control over and know that the destructor doesn't do anything other than free memory.

    Since it is an optimization hack, it should not be used unless there is a serious performance problem during program shutdown that cannot be resolved in any other way. If used incorrectly, this hack could be dangerous and leak resources that don't get automatically cleaned up by the OS.

  12. #42
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,308
    The thing I think we'll all agree on is that probably in most cases, programs that don't clean up their resources upon exit are the ones that leak like a sieve whilst they're running as well.
    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"

  13. #43
    and the hat of sweating
    Join Date
    Aug 2007
    Location
    Toronto, ON
    Posts
    3,545
    Quote Originally Posted by iMalc View Post
    The thing I think we'll all agree on is that probably in most cases, programs that don't clean up their resources upon exit are the ones that leak like a sieve whilst they're running as well.
    Well obviously this hack should only be used for objects that live from the start of the program to the end. Not using delete for any object in the program would just be crazy.

  14. #44
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,768
    Quote Originally Posted by brewbuck View Post
    Except that what you're talking about isn't even possible. Many modern operating systems won't even ALLOW you to give memory back to the OS once you've acquired it. Your program's data size can grow but not shrink.

    So how is a user application supposed to release all resources if it's not even possible?

    Again, this is different from destructing objects. Freeing memory is only a part of that picture.
    FYI, if you get memory using new, then free it using delete.
    Whether or not it returns to the OS is OS specific and we can't do a darn thing about it - so let's just think about it this way: You call new, then you call delete, and there your responsibility ends. Now it's up to the OS.

    Quote Originally Posted by King Mir View Post
    So you're saying it would not be safe? I think most people here seem to disagree. If it is safe then it is a benefit. Sure, there is a trade off involved, but Sometimes optimization does win over style.
    It should not be safe. Or should not be possible, or something. Optimization or not, I do not like the idea of doing this at all, for all reasons mentioned above.

    If one of the features of an application you are developing is the ability to safely suddenly terminate at any time, then it is safe to call exit() at any time to force such a termination. Since the feature is there, one may as well use it to quickly close the application. It's fast and guaranteed to work.
    And how many programs can safely shut down and does not have some work to do when shutting down? Saving settings, perhaps? It's far better and safer to just shut down the normal way and let all destructors and cleanup code run.

    I'd be willing to consider an argument saying that the optimization is negligible, particularly if evidence was provided. But your argument seems to be most based mostly on stylistic grounds, which take a back seat once optimization kicks in.
    FYI, I haven't had a single problem where the application takes too long time to shut down as opposed to startup time.
    Though typically it's also true that I don't run that much cleanup code since I make sure everything is saved properly the first time it's done (like saving settings), as to safeguard from crashes and unindented computer shutdowns.
    But I would never think of purposely not freeing all resources and getting the OS to do it for you.
    Last edited by Elysia; 01-06-2008 at 04:52 AM.
    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.

  15. #45
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,248
    Quote Originally Posted by Elysia View Post
    FYI, if you get memory using new, then free it using delete.
    Whether or not it returns to the OS is OS specific and we can't do a darn thing about it - so let's just think about it this way: You call new, then you call delete, and there your responsibility ends. Now it's up to the OS.
    Once again, I already said that you should delete all objects.

    It should not be safe. Or should not be possible, or something. Optimization or not, I do not like the idea of doing this at all, for all reasons mentioned above.
    So we should poison the operating system so it explodes if someone does something Elysia doesn't like?

    FYI, I haven't had a single problem where the application takes too long time to shut down as opposed to startup time.
    Enough "FYI" already. Where the hell have you developed this wellspring of experience anyway?

Page 3 of 4 FirstFirst 1234 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. HELP with Program!
    By afnitti in forum C Programming
    Replies: 9
    Last Post: 04-15-2009, 08:06 PM
  2. exit a program at any point.
    By slightofhand in forum C Programming
    Replies: 5
    Last Post: 03-02-2008, 08:08 AM
  3. Program Terminating With Error On Exit
    By chriscolden in forum C Programming
    Replies: 19
    Last Post: 01-14-2006, 03:40 AM
  4. Program uses a lot of memory and doesnt exit properly
    By TJJ in forum Windows Programming
    Replies: 13
    Last Post: 04-28-2004, 03:13 AM
  5. My program, anyhelp
    By @licomb in forum C Programming
    Replies: 14
    Last Post: 08-14-2001, 10:04 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21