Concerning delete/delete[] at program exit

Stroustrup begins his answer to the his FAQ on How do I deal with memory leaks? by saying:

Quote:

---

By writing code that doesn't have any. Clearly, if your code has new operations, delete operations, and pointer arithmetic all over the place, you are going to mess up somewhere and get leaks, stray pointers, etc. This is true independently of how conscientious you are with your allocations: eventually the complexity of the code will overcome the time and effort you can afford. It follows that successful techniques rely on hiding allocation and deallocation inside more manageable types. Good examples are the standard containers. They manage memory for their elements better than you could without disproportionate effort.

---

Well and good. At the same time, I have heard the argument that since (most of the common) operating systems reclaim memory used by a program when it quits, it is not necessary to use delete/delete[] on objects created with new/new[] that last till the end of the program, unless their destruction does something that the operating system will not do.

After reading through several examples in the FLTK documentation, I assumed that either FLTK handled the freeing of memory, or the examples were relying on the operating system to do the job. Some searching brought me to a thread (WTF new -> delete where a user had the same concerns.

The responses basically went over this issue, though some took the position that deletes at program exit were neither necessary nor harmful, others stated that it was not necessary and potentially harmful, and the thread starter insisted that it was necessary.

So, what is your take on this?

Well what if the memory is allocated in shared memory?

Also, if you run a tool that checks for memory leaks, it will probably find your intentional leak and cause some managers to assume the worst...

If your code is modified several years down the road, and now your pointer(s) lifetimes are changed, the person making the changes might not realize you forgot to delete it and then you end up with a real leak...

I wouldn't buy any argument about it being "potentially harmful". That can only be just nonsense.
I think that the best option is always to try and free everything upon exiting. If you use leak detection tools, then it's just so much easier to spot the single new leak at the time you add it instead of having to wade through 1000 leaks to see find one which is new. The chances of having a large number of one-off unimportant leaks is pretty small anyway.

My take is that it is ok for non-beginners to not release memory at program termination, if there is a good reason, namely it would lead to much simpler code.

In C, I could see an argument where it is much simpler to call exit(1) in a situation where a terminal error arises, rather than build in an exception propagation system into every function to ensure that memory is freed. In C++, exception propagation is built in and the use of smart pointers allows for all memory to be easily freed when an error occurs. So in regular C++ I can think of no reason not to release memory on exit. Of course my lack of creativity does not imply that no reason exists, I just can't think of one.

> The responses basically went over this issue, though some took the position that deletes
> at program exit were neither necessary nor harmful, others stated that it was not necessary
> and potentially harmful, and the thread starter insisted that it was necessary.
There are two kinds of allocation which you need to watch out for:
- allocations in response to some kind of event always need to be freed, otherwise they will erode the pool of available memory until there is no more and the program crashes.
- allocations at start-up which are held for the life of the program. In most(*) cases, it is OK to let the OS catch these, though there is no need to be lazy about it IMO.

I agree with iMalc, it's a lot easier to spot new (and potentially serious) leaks if you keep the program pretty clean to begin with.

(*) Your average consumer-level desktop OS would be fine. An embedded RTOS without memory management would fare a lot worse.

A lot of desktop programs seem to leak something or other if you run them for long enough. My guess is that the assumption is the user will quit the application or turn off the machine at some regular interval. But in say a data centre, or an embedded platform such as a mobile phone, people expect months of continuous "uptime", so there is no room for even the smallest leak.

I don't know about FLTK, but in wxWidgets controls are allocated with new but delete is rather rare: descendants will be released by parents, and the parent frame would be freed with the Destroy member function.

So this might be a library peculiarity.

Never let any memory you allocated go unfreed, is my take on everything. Of course, it can't be helped if an error occurs and the program is killed implicitly (runtime error, for example), but you should nevertheless avoid such a thing.
In C++, this argument is void due to smart pointers and RAII; no resource should ever be leaked. If I find a memory leak in my program, regardless if it's due to not calling delete at memory when exiting or if it's just a subtle leak somewhere else that I missed to free, I hunt them down and fix them.

When you are in charge of memory allocation yourself, it's not the time to be lazy. All memory you allocate should be freed, even if it's automatically freed when the program exits. This is just so sloppy programming...

Quote:

---

If your code is modified several years down the road, and now your pointer(s) lifetimes are changed, the person making the changes might not realize you forgot to delete it and then you end up with a real leak...

---

Yes, this echos Stroustrup's point but with the issue of long term maintenance, though unfortunately the anonymous user who started that thread never mentioned it.

Quote:

---

I wouldn't buy any argument about it being "potentially harmful". That can only be just nonsense.

---

Greg Ercolano claimed otherwise:

Quote:

---

But in actual practice, when you know the OS is working for you,
you can actually save quite a bit of backflipping by leaving the OS
to do the delete unless absolutely necessary.

Write a few hundred programs, and you begin to realize the delete's
aren't needed, and can sometimes cause program exit time to be
so significant, that it's actually better NOT to call all the destructors.
Some programs are so pendantic about calling destructors, that when you
hit "File|Quit", they take minutes to exit. Whereas just exit()ing the
program takes seconds, deallocating everything in one shot.

---

Frankly, I never experienced the vague anecdotal evidence that he provided. I have used programs with slow startup, not exit, time, especially Java programs :p

Quote:

---

I don't know about FLTK, but in wxWidgets controls are allocated with new but delete is rather rare: descendants will be released by parents, and the parent frame would be freed with the Destroy member function.

So this might be a library peculiarity.

---

Yes, that appears to be FLTK's behaviour. However, this is a separate point from delete at exit since this concerns delete before exit.

Quote:

---

Never let any memory you allocated go unfreed, is my take on everything.

---

Indeed, but these guys are saying that the OS is going to free the memory you allocated, so all is well. Note of course that the operating systems they have in mind are not some embedded RTOS without memory management as Salem mentioned. If you would raise this issue (as is my normal argument for always matching new/new[] with delete/delete[] respectively) I expect that they would dismiss it with 'every operating system (that FLTK deals with) keeps track of all allocations and frees those without the need to call "delete"'.

Quote:

---

When you are in charge of memory allocation yourself, it's not the time to be lazy. All memory you allocate should be freed, even if it's automatically freed when the program exits. This is just so sloppy programming...

---

How would you address Ian MacArthur's claim that:

Quote:

---

As has been explained elsewhere in this thread, any objects that are to be deleted on program termination will be automatically tidied away by the operating system when the program exits.

Therefore, you only have to call the destructors for objects that are created and deleted dynamically as your program executes, or for objects whose destructor performs some action that the O/S can't or won't do for you on termination. (The standard fltk objects do not fall into that category.)

So you can call them if you want to. And they will work.
But if you do, your program will take a little longer to shut down, and it will make no difference at all to the O/S. There are no known resource leaks in 1.1.7.

I don't know what you have been taught, or what you have read, but this actually does constitute correct and proper practice.

---

Note that the emphasis is mine for the bold text.

I have never seen any evidence to suggest that normal memory allocations in an operating system like Linux or Windows would ever cause any problem by not being freed. The "exit()" function [or the system call that it results in] should take care of closing files, deallocating memory allocations, decrementing reference counts for shared resources and such, including device drivers.

If this was not the case, all applications that crash would lead to memory leaks, resource leaks, etc.

Unfortunately, there are drivers that don't "play nice", so sometimes, terminating a driver connection "the correct way" is necessary to prevent problems.

But for common memory allocations and such, the only real problem with not deleting or freeing the memory is if you continualy allocate memory that is never used again, you will eventually run out of memory. This is more of a problem with long-running applications. Similarly, of course, if the creation of an object binds some system resource, you can't just allocate more and more of them, or the system will (probably) eventually run out of that type of resource.

--
Mats

Quote:

---

Originally Posted by laserlight

Greg Ercolano claimed otherwise:

Frankly, I never experienced the vague anecdotal evidence that he provided. I have used programs with slow startup, not exit, time, especially Java programs :p

---

That's just nonsense.
If your app takes a long time to shut down, why not just hide the GUI and let the program finish its work in the background? You could even set the thread priority to Idle to let it go unnoticed. I don't buy that argument that you shouldn't let the app handle cleanup if it takes too long time. That's just a sloppy argument.

Quote:

---

Indeed, but these guys are saying that the OS is going to free the memory you allocated, so all is well. Note of course that the operating systems they have in mind are not some embedded RTOS without memory management as Salem mentioned. If you would raise this issue (as is my normal argument for always matching new/new[] with delete/delete[] respectively) I expect that they would dismiss it with 'every operating system (that FLTK deals with) keeps track of all allocations and frees those without the need to call "delete"'.

---

POC to that. Who says the OS doesn't need to clean up what the application doesn't? Let's think about it for a while.
If an application cleans up everything, it needs to free all memory that it owns, etc. It may take some time.
But if your app doesn't do this and just quits, then the OS must clean up everything from the application, which must take just about as much time. So there's no gain there, is it?

Quote:

---

How would you address Ian MacArthur's claim that:

Note that the emphasis is mine for the bold text.

---

I don't know who has taught Ian that, but I don't consider it proper practice!
It does make a difference to the OS, if you want to argue, because if YOU don't clean up, IT has to, so in the end, there's no benefits to having the OS do it.

There are further bad practices in doing this, as well. Memory leak programs will catch these leaks. You'll get bombarded with leaks when using MFC, for example, since it automatically dumps memory leaks when a debugging session is finished if there was any.
Not to mention, what if there's a bug in the OS or it can't handle it very well?
*cough* Windows 95 *cough*
And what if this code is going to be ported to an OS which does not do this?
Since this is a forum that teaches portability, I would further argue that you clean up everything you use. No excuses such as "the OS does it for me." Now that sounds like a VB programmer who does not declare variables before using them or just use variants for everything. Argh, I hate those.

Quote:

---

But if your app doesn't do this and just quits, then the OS must clean up everything from the application, which must take just about as much time. So there's no gain there, is it?

---

Not true. If, for example, you have memory allocated, and you deallocate it, the allocator must still maintain the integrity of its management data structures through every single deletion.
If, on the other hand, the OS frees the stuff, it simply sets all memory pages used by your app to "free" again. Much faster.

If the OS was designed that way, yes. But you can't be sure of that.
And just leaving it to the OS to do is what I find sloppy, just like a VB programmers.

Quote:

---

Originally Posted by Elysia

If the OS was designed that way, yes. But you can't be sure of that.
And just leaving it to the OS to do is what I find sloppy, just like a VB programmers.

---

In the OS's view, memory exists in chunks of 4KB or multiples thereof - in fact, the Windows heap is created with "HeapCreate()", and the destruction of that can easily be done by just marking all it's pages as free - that's much quicker than walking all over the place calling destructors that delete member variables, and THEN freeing the entire heap anyways.

--
Mats

Not calling destructors is very bad practice. This is another reason I'd put for explicitly deleting all data inside the program.
Calling the destructors but not freeing the actual objects is also bad programming practice since these objects will be left in a zombie state.

Quote:

---

Originally Posted by Elysia

Not calling destructors is very bad practice. This is another reason I'd put for explicitly deleting all data inside the program.
Calling the destructors but not freeing the actual objects is also bad programming practice since these objects will be left in a zombie state.

---

Well, we're assuming that we have done the necessary work to "finish" the program. What is, then, the problem with just exiting? What "good" will calling all the destructors actually do? Unless the OS [or some components like drivers] is buggy, the OS should free anything that the application "holds" - there is no need to delete every single object.

Note, I'm not saying this is how I would do things in my programs - in fact, at work, we have a heap-tracker that tracks every allocation, and REQUIRES that we free everything - this is tested in the test-code for each individual test-case.

--
Mats

Quote:

---

I don't know who has taught Ian that, but I don't consider it proper practice!

---

Has any expert say, at work, considered it otherwise? Note that the general response in the thread I linked to considered it proper practice.

Quote:

---

And what if this code is going to be ported to an OS which does not do this?
Since this is a forum that teaches portability, I would further argue that you clean up everything you use.

---

That we are usually concerned with portability here does not matter. Consider that I might use the arguments in this thread and start a thread in the FLTK mailing list. I certainly cannot say "since one of FLTK's goals is portability" since they would point out that "FLTK is a cross-platform C++ GUI toolkit for UNIX/Linux (X11), Microsoft Windows, and MacOS X".

Quote:

---

No excuses such as "the OS does it for me." Now that sounds like a VB programmer who does not declare variables before using them or just use variants for everything.

---

First, you have to establish that it is an excuse. Some of these FLTK users are saying that it is deliberate as a kind of optimisation.

Quote:

---

Not calling destructors is very bad practice.

---

How is not calling destructors very bad practice if they have no side effect other than to free memory that would otherwise be freed by the OS just afterwards?

Quote:

---

Calling the destructors but not freeing the actual objects is also bad programming practice since these objects will be left in a zombie state.

---

How does this matter if the program has exited?

Quote:

---

Originally Posted by laserlight

Has any expert say, at work, considered it otherwise? Note that the general response in the thread I linked to considered it proper practice.

---

Yes, they do seem to find it proper practice, and they're entitled to believe what they want, and so am I, and I don't find it proper practice. Unless someone can point to a real source where it specifically says it's good programming practice.

Quote:

---

That we are usually concerned with portability here does not matter. Consider that I might use the arguments in this thread and start a thread in the FLTK mailing list. I certainly cannot say "since one of FLTK's goals is portability" since they would point out that "FLTK is a cross-platform C++ GUI toolkit for UNIX/Linux (X11), Microsoft Windows, and MacOS X".

---

They obviously do not listen to anyone who says they should explicitly call delete, and frankly, it's their project, so they're entitled to do what they want and not listen to anyone else.
To tell the truth, I'm sick of their attitude when I read about they not explicitly calling delete and saying it's good practice.
This may just be me, but I'll definitely stay away both from that forum and from their project. Not that it does me any good or them any harm, but I don't like it and thus I won't use it. Simple.

Quote:

---

First, you have to establish that it is an excuse. Some of these FLTK users are saying that it is deliberate as a kind of optimisation.

---

It's an optimization only if the world was made of ice.
It reflects my own opinions and not theirs.

Quote:

---

How is not calling destructors very bad practice if they have no side effect other than to free memory that would otherwise be freed by the OS just afterwards?

---

Why do we have destructors?
Who says destructs are limited only to freeing resources?
I can do so much more, such as flushing some memory to a file, for example.
So if the destructor isn't called... the file data is never written.
I could find this to be a valid scenario since file writing is slow and thus I'd like to keep all data in memory and flush it only when necessary, since the code might be time critical.

Oh right, and if the class is actually dervied and work is performed in those destructors? Uh-oh...

The point is, instead of worrying for some bugs and causing headaches for those who want to use and derive that code, why not just save everyone trouble and explicitly call delete? No worrying bugs about destructors not being called!

Quote:

---

How does this matter if the program has exited?

---

The program does not exit when a destructor is called. It will exit AFTER it's called. And after that destructor, more code is possible executed and perhaps this "zombie state" object gets used somehow.
It's a possibility.

And btw, I have an analogy for this whole OS clean up argument. No, it may not be any good, but it sure annoys me.
If your job is to cut grass and you actually have to pick up all the crap people has thrown on that grass because they didn't do something as simple as toss it into a recycle bin, wouldn't you be annoyed to, especially since it isn't really part of your "job"?
I sure would be.
And that is why, everyone should toss stuff into the recycle bin and not leave it for someone else to clean up. Aka, the program should delete any resources it acquires and not leave it to the OS to clean up.

Quote:

---

Who says destructs are limited only to freeing resources?
I can do so much more, such as flushing some memory to a file, for example.
So if the destructor isn't called... the file data is never written.

---

If the destructor does something you need, surely you will delete that object.

Quote:

---

The program does not exit when a destructor is called. It will exit AFTER it's called. And after that destructor, more code is possible executed and perhaps this "zombie state" object gets used somehow.
It's a possibility.

---

So if freeing memory may create zombie objects, wouldn't it be better not to delete them?

Quote:

---

If your job is to cut grass and you actually have to pick up all the crap people has thrown on that grass because they didn't do something as simple as toss it into a recycle bin, wouldn't you be annoyed to, especially since it isn't really part of your "job"?

---

And if you know that a machine will come and clean away the grass after you have left?

And again, I don't think anyone suggests optimizing away necessary operations.

Quote:

---

Originally Posted by anon

If the destructor does something you need, surely you will delete that object.

So if freeing memory may create zombie objects, wouldn't it be better not to delete them?

---

That was my point - delete everything so you avoid subtle but nasty bugs.
Good programming practice.
And if the authors didn't delete the object because they didn't need to - what happens if someone else derives that object but doesn't realize the framework doesn't delete the base object? Nasty bug right there.

Quote:

---

And if you know that a machine will come and clean away the grass after you have left?
And again, I don't think anyone suggests optimizing away necessary operations.

---

I know it won't, but it's just the WHY I always like to think that you are responsible for cleaning up that which you create or get.

I agree with Elysia.
Pointers aren't the only thing that destructors clean up. I've seen several WinAPI functions that have big NOTES in them about calling the corresponding cleanup function when you're done to avoid bad things happening. I don't remember which functions they were, but they're probably not that hard to find.

Also, even if a destructor only deletes memory today, tomorrow it might be updated to do other types of cleanup that aren't handled automatically by the OS when the program exits.

I think the FLTK have a good point. It is an optimization to not free memory. As an optimization, it should not be made prematurely -- the coder needs to be sure that there is a potencial slowdown for the destructor calls and that there is no chance for a leak. But like all trade offs, theres a time and place for either option.

Their attitude, that not deleting is default practice, however, seems questionable. If they are making an optimization, they should be conscious of it.

I had no idea this thread was going to be concerned with abnormal program termination.
Sure, if something awful happens, I'm fine with a process terminating itself abruptly. This should not be the norm though.

If a process does take a while to run all its destructors to close the program then I'd say some profiling would be in order. In all liklihood there'll be a destructor for one type of object that takes extraordinarily long, and optimising it would speed the program up a lot in general. I don't think that purely deallocation would ever take very long at all. Even if it did, it would have to be due to a massive number of small allocations that should be being done through a pool allocator for a big general program speed improvement anyway.

I know Visual studio often takes some time to close, but I think the IDE is poorly optimised, and does stuff at closedown that probably shouldn't be done.

I suppose the memory freeing could be a release-build-only optimisation. The main thing is to catch all leaks in a debug build.

Visual Studio is .NET, which probably explains why it takes so long to close due to the stupid framework having to clean up and shutdown, as bloated as it is.

Quote:

---

Originally Posted by Elysia

If the OS was designed that way, yes. But you can't be sure of that.

---

An OS that doesn't clean up memory from terminated processes is a broken OS. The story is different, of course, on embedded systems, where the line between OS and application is blurred.

(Having said that, I stand on the "always delete everything" side of the fence.)

I agree with Elysia, cpjust, and iMalc. Except for the release optimization thing. I expect a well-written program to clean up after itself.

I see the OS cleaning up after programs are finished running is something of a patch. It was made because buggy programs didn't release all their memory and/or resources, and it was necessary to make a stable OS platform. I don't think a patch should be relied on.

As far as the destructors not being called, that's just stupid. Some reasons have been been explained above. (inheritance... why rely on not using inheritance when the code allows it to be done?)

As far as not calling delete in the examples, that's stupid because the examples are meant to show how to use the code in a larger program, not how to make an optimized example program.

If they do insist on doing that, then I would suggest putting it in compiler/OS specific code, and offer code that uses delete as well. I would prefer it if the code that used the delete were the default.

Like Elysia, I don't think I'll be using it in my real world programs if it doesn't clean up after itself, or won't do so after some minor inheritance.

Quote:

---

Originally Posted by brewbuck

An OS that doesn't clean up memory from terminated processes is a broken OS. The story is different, of course, on embedded systems, where the line between OS and application is blurred.

---

Indeed! But perhaps it is an embedded system. OR something else that just won't clean up. It's better to just explicitly release everything so you are sure you won't be creating bugs on purpose.

Quote:

---

Originally Posted by robwhit

I see the OS cleaning up after programs are finished running is something of a patch. It was made because buggy programs didn't release all their memory and/or resources, and it was necessary to make a stable OS platform. I don't think a patch should be relied on.

---

The stability of the OS should not depend on the behavior of user applications. That's the entire point of having an operating system. It's not a patch, it's a fundamental step forward.

Quote:

---

Originally Posted by Elysia

Indeed! But perhaps it is an embedded system. OR something else that just won't clean up. It's better to just explicitly release everything so you are sure you won't be creating bugs on purpose.

---

Yes, but if you're writing something that is not to be used on an embedded system and have determined that your program does not leak, would it not be safe to optimize program termination? Many programs I use take a few seconds to shut down, and I do not see that as a plus.

The optimization especially makes in an environment where you want the application to be invulnerable to a power outage or OS crash.

Of course a big downside to sudden termination is that having exit(1) buried deep within you code makes your code hard to expand later to deal with those errors in other ways (such as by writing to the log), particularly if it is somebody else expanding your code.

Quote:

---

Originally Posted by brewbuck

The stability of the OS should not depend on the behavior of user applications. That's the entire point of having an operating system. It's not a patch, it's a fundamental step forward.

---

It's a patch! To keep the OS stable even if an app crash or does weird things.
Of course the OS needs to do that or we'd be back in the Windows 95 days.

Quote:

---

Originally Posted by King Mir

Yes, but if you're writing something that is not to be used on an embedded system and have determined that your program does not leak, would it not be safe to optimize program termination? Many programs I use take a few seconds to shut down, and I do not see that as a plus.

---

No, I disagree. Even if programs take time to close down, they can do so in the background.

Quote:

---

The optimization especially makes in an environment where you want the application to be invulnerable to a power outage or OS crash.

---

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!)

Quote:

---

Of course a big downside to sudden termination is that having exit(1) buried deep within you code makes your code hard to expand later to deal with those errors in other ways (such as by writing to the log), particularly if it is somebody else expanding your code.

---

And those are big downsides. 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.
And hey... what if the program DOES require interaction when it quits? Bye-bye to the OS patch-up instead of the program.

Quote:

---

Originally Posted by Elysia

It's a patch! To keep the OS stable even if an app crash or does weird things.
Of course the OS needs to do that or we'd be back in the Windows 95 days.

---

This opinion is frankly ridiculous. There are two sides to this question:

1) Should the OS reclaim user program memory when programs terminate? YES.
2) Should the user program itself rely on this behavior? NO.

The answer to question 2 is not "no" because we aren't sure the OS will reclaim the memory -- of course it will. The answer is "no" because it's good design. Those objects presumably have destructors, and those destructors should run.

Calling the difference between DOS (a system without memory protection) and any modern OS a "patch" is freaking nuts. The only reason DOS itself didn't have memory protection is because the home computer hardware at the time didn't support it. This idea was not invented in 1995.

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.

> 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.

Quote:

---

Originally Posted by Elysia

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.

Quote:

---

Originally Posted by robwhit

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.

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.

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 Elysia

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?

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 Elysia

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.

Quote:

---

Originally Posted by Elysia

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.

Quote:

---

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.

Quote:

---

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.

Quote:

---

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.

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.

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.

Quote:

---

Originally Posted by iMalc

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.

Quote:

---

Originally Posted by brewbuck

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

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.

Quote:

---

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.

Quote:

---

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.

Quote:

---

Originally Posted by Elysia

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.

Quote:

---

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?

Quote:

---

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?

Quote:

---

Originally Posted by brewbuck

So we should poison the operating system so it explodes if someone does something Elysia doesn't like?

---

My opinion. Not relevant to you.

Quote:

---

Enough "FYI" already. Where the hell have you developed this wellspring of experience anyway?

---

Ha! Only the gods know!

Quote:

---

Originally Posted by Elysia

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.

---

Most programs are liable to crash, without cleanup. Therefore the ability of an OS to safely cleanup is a vital feature that can be relied upon. If someone has an OS that cannot properly handle an application crash, then I suggest they get a new one.

Quote:

---

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.

---

You're missing my point. There times when such a feature is a vital requirement -- an application must be able to safely and completely recover from a sudden system shutdown. Given such an application, one may as well take advantage of the feature to speed up the normal quiting process.

Quote:

---

Originally Posted by King Mir

Most programs are liable to crash, without cleanup. Therefore the ability of an OS to safely cleanup is a vital feature that can be relied upon. If someone has an OS that cannot properly handle an application crash, then I suggest they get a new one.

---

Of course. Due to all the poor written applications out there, the OS just has to have a feature to clean up the mess of programs. Sure. I can get that.

Quote:

---

You're missing my point. There times when such a feature is a vital requirement -- an application must be able to safely and completely recover from a sudden system shutdown. Given such an application, one may as well take advantage of the feature to speed up the normal quiting process.

---

This is a good thing but that does not give it the right to just exit or crash or whatever and force the OS to cleanup its mess.
As has been mentioned before, shutdown should not take long time and if it does, then it's probably not memory-related but destructors that needs to be optimized.
And even if it takes long, it's far safer to let everything clean up the normal way in a background thread.

Elysia, although I agree with you on this for 99.99% of the programs out there - they should always clean up their own mess, I think the point of this discussion is that this "technique" is an optimization. So as any optimization, it should be used very carefully and only when the benefit outweighs the cost.

Optimizations do not need to be applied when applications are terminating IMO, but whatever.
And I cannot agree it is an optimization; it's a hack.

Quote:

---

Originally Posted by brewbuck

The stability of the OS should not depend on the behavior of user applications. That's the entire point of having an operating system. It's not a patch, it's a fundamental step forward.

---

I was going to argue this point. Then I realized it was just my opinion and it was irrelevant.

Quote:

---

Originally Posted by Elysia

No, I disagree. Even if programs take time to close down, they can do so in the background.

---

Even shutdown time is something that you could use to be doing something else.

Quote:

---

Originally Posted by brewbuck

Calling the difference between DOS (a system without memory protection) and any modern OS a "patch" is freaking nuts. The only reason DOS itself didn't have memory protection is because the home computer hardware at the time didn't support it.

---

I didn't mean it was patching the OS, but rather the application.

Quote:

---

Originally Posted by brewbuck

and for that matter how DOES a user application "free the stack" anyway?

---

Nothing suggested that you have to do that. And you didn't allocate it so why should you have to free it? And what is a stack anyways?

Quote:

---

Originally Posted by brewbuck

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.

---

Really? Can you support this?

Quote:

---

Originally Posted by King Mir

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.

---

There's also atexit.

Quote:

---

It's fast and guaranteed to work.

---

Code:

---

void do_this()
{
    for(;;);
    return;
}

int main()
{
    atexit(do_this);
    exit();

    return 0;
}

---

Quote:

---

Originally Posted by cpjust

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.

---

I don't see what memory protection has to do with this.

Quote:

---

Originally Posted by Elysia

And how many programs can safely shut down and does not have some work to do when shutting down?

---

Are you talking about from a library perspective or an application perspective?

Quote:

---

Saving settings, perhaps?

---

That's what fflush, fclose, and unbuffered output are for.

Hey George2, that's how you use the multi-quote feature.

Quote:

---

Originally Posted by robwhit

Are you talking about from a library perspective or an application perspective?

---

From an application perspective, perhaps even library, all the same.

Quote:

---

That's what fflush, fclose, and unbuffered output are for.

---

But then again, the code has to execute to do that, doesn't it? So that means you can't call exit. And if it's placed inside a destructor, you need to delete that object.

Quote:

---

Originally Posted by Elysia

But then again, the code has to execute to do that, doesn't it? So that means you can't call exit. And if it's placed inside a destructor, you need to delete that object.

---

Then put it in atexit().

Quote:

---

Originally Posted by cpjust

Then put it in atexit().

---

That would probably be an awful idea since you have no idea where and why atexit was called.

But Elysia, I think you are taking it all too religiously. I guess very few people would disagree that proper code would delete all resources, and noone would disagree that you absolutely have to delete some resources.

But if you have something like a FLTK_Window which is guaranteed not to do anything (useful) in its destructor, heaven and earth won't collapse if you fail to delete it at program termination.

In the referred thread someone also mentions that omitting deletes may be so as to not complicate simple examples with irrelevant details. Just like error handling for input is omitted in most example programs.

But may-be you should try to enlighten them?

If I tried to enlighten them, they'd probably sneeze at me, saying it's not necessary.
But I'd love to see their faces when something breaks and they have to go to great lengths to fix it simply because they're not deleting what they allocate.
I'd also love to see their faces if the OS didn't clean up their mess. Though I doubt that will ever happen.

Quote:

---

Calling the difference between DOS (a system without memory protection) and any modern OS a "patch" is freaking nuts. The only reason DOS itself didn't have memory protection is because the home computer hardware at the time didn't support it.

---

As has been said this ability has been in Intel processors for a very very long time. Microsoft just decided to start using it very late in the game. I believe it all started with the 386 but I do remember some blurbs from way back about the 286 having some type of special 'mode' that was almost like protected mode. However it was not used often because it was clunky and not very stable. Matsp would probably know more about this than I.

To me not cleaning up memory at program exit because the OS will do it for you is both lazy and a hack. To say it is an optimization is quite a stretch. In my 23 years of working with computers I can remember about 5 times I complained about a program shutting down too slow. Usually they startup and run too slow. It's not because none of them were slow but it's probably due to perception. At shutdown I'm done with the application and don't care what it does or how fast it is. At startup or during runtime I do. So optimize the startup and the runtime I don't really care about shutdown.

I just cannot vote for the side that says not cleaning up memory at exit is a valid practice. We all agree it's not a good practice in an embedded environment and I say it's also equally not good in a non-embedded environment.

Yes the OS will clean up for you as a courtesy to the other programs to keep the system stable. It's not designed so that programmers can be lazy and thoughtless at shutdown and force or rely 100% on the OS to clean up. The end result here is not the issue. It's not the fact that it will work either. It's the fact that regardless of the outcome, it's not a good practice.

Just my two cents.

I expected that more people would reply to my post. Oh well. Guess I'll wrap up my train of thought.

Well, I think it all comes down to whether the OS releasing memory is a documented feature of Windows or some API, so that it can be relied upon, not just some expectant realization.

That's all I have to say on the subject.

edit: except for this:

Quote:

---

That would probably be an awful idea since you have no idea where and why atexit was called.

---

It's called by exit. well... the function passed to it is. That's what you meant, right?

edit2: and that I don't think it should be done in C++ because there might be some sort of compiler-added overload in the destructors, so the only way you could do it cleanly in C++ was with malloc and with OS extensions, or with compiler and OS extensions.

I'm with Bubba on this and I doubt you'll find any API or documentation on that it does this. Or if you do, I don't think you'll find it says "you can just avoid cleaning up so Windows can do it for you."

Quote:

---

Originally Posted by Elysia

I'm with Bubba on this and I doubt you'll find any API or documentation on that it does this. Or if you do, I don't think you'll find it says "you can just avoid cleaning up so Windows can do it for you."

---

I think it's very bad practice too, but none the less, it should be safe when used VERY carefully on the right platform, and it should shutdown a lot faster. That being said -- don't do it. ;)