Thread: Concerning delete/delete[] at program exit

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.

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

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.

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?

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?

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.

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.

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.

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!

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.

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.

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?

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.

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.

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

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.

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.

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.

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.

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

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.