My opinion. Not relevant to you.Originally Posted by brewbuck
Ha! Only the gods know!Enough "FYI" already. Where the hell have you developed this wellspring of experience anyway?
My opinion. Not relevant to you.
Ha! Only the gods know!Enough "FYI" already. Where the hell have you developed this wellspring of experience anyway?
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.
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.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.
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.
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.
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.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.
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.
I was going to argue this point. Then I realized it was just my opinion and it was irrelevant.
Even shutdown time is something that you could use to be doing something else.
I didn't mean it was patching the OS, but rather the application.
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?
Really? Can you support this?
There's also atexit.It's fast and guaranteed to work.Code:void do_this() { for(;;); return; } int main() { atexit(do_this); exit(); return 0; }I don't see what memory protection has to do with this.
Are you talking about from a library perspective or an application perspective?That's what fflush, fclose, and unbuffered output are for.Saving settings, perhaps?
Hey George2, that's how you use the multi-quote feature.
From an application perspective, perhaps even library, all the same.
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.That's what fflush, fclose, and unbuffered output are for.
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?
I might be wrong.
Quoted more than 1000 times (I hope).Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.
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.
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.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.
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.
Last edited by VirtualAce; 01-07-2008 at 06:08 PM.
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:It's called by exit. well... the function passed to it is. That's what you meant, right?That would probably be an awful idea since you have no idea where and why atexit was called.
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.
Last edited by robwhit; 01-09-2008 at 01:59 PM.
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.
