0

I'd like to know if freeing your whole program upon exit is a good practice or not. Of course I know memory is reclaimed by the system anyway.

Here, I'd like to know if quite experienced C developers tend to encourage such practice or not.

Thanks.

Ra'Jiska
  • 979
  • 2
  • 11
  • 23
  • `freeing your whole program upon exit `...what is that? – Sourav Ghosh May 24 '17 at 11:39
  • 4
    Yes, it's good practice, if _freeing your whole program upon exit_ means _freeing all memory that has been allocated with `malloc` and similar functions_. – Jabberwocky May 24 '17 at 11:40
  • How is not opinion-based? – Sourav Ghosh May 24 '17 at 11:41
  • 1
    @SouravGhosh see Bathsheba's answer. – Jabberwocky May 24 '17 at 11:41
  • 2
    @SouravGhosh Since there are valid rational arguments for it, I do not consider it opinion based. – Ctx May 24 '17 at 11:42
  • @Ctx There are counter arguments too, I've read them. It goes like what's the point of cleaning the floor while the house is burning down? – Sourav Ghosh May 24 '17 at 11:43
  • @SouravGhosh It's the same with our old discussion about casting malloc, there are also arguments for and against it. So it's primarily opinion based? – Ctx May 24 '17 at 11:44
  • @Ctx Nopes, not casting malloc atleast saves you from not having header included. Anything for `free(p);` before `exit(0);`? – Sourav Ghosh May 24 '17 at 11:45
  • 1
    SouravGhosh: Yes, valid pro and con arguments are listed in the answer below and in the answers of the duplicate question linked. – Ctx May 24 '17 at 11:47
  • @Ctx I already left a comment there, thanks. ;) – Sourav Ghosh May 24 '17 at 11:49
  • It is opinion-based. Many skilled, experienced and high-rep developers believe in explicitly freeing resources on process termination, even though they cannot guaranteee to do so safely, have no answer to shutting down complex multi-threaded code running on multiple cores, are already using libraries that acknolwdge this and don't free stuff, and are just wrong :) – ThingyWotsit May 24 '17 at 14:23

1 Answers1

5

You should always clean up your memory. Don't rely on an operating system to do it.

Going forward, you might find your program being part of an environment where the memory is not freed for you, and retro-fitting such code could prove tricky.

Bathsheba
  • 231,907
  • 34
  • 361
  • 483
  • `an environment where the memory is not freed for you`...an example sir, if I may ask? – Sourav Ghosh May 24 '17 at 11:45
  • 1
    @SouravGhosh: take AmigaOS for instance. There's no resource tracking on exiting processes. Ok it's ancient history, but it exists. – Jean-François Fabre May 24 '17 at 11:50
  • @SouravGhosh as the question is not specifically about memory but resources than you should always release resources you own. For ex. try not to clean some COM objects and you will end up for ex. with black screen, not editable files etc. – Logman May 24 '17 at 11:55
  • On most OS, you should not clean up memory unless there is an overriding reason to do so. The main reason? You cannot do it safely from user code. Only the OS can guarantee to stop all threads before releasing memory. Modern OS have hundreds of thousands of hours of testing, a hardware inter-core comms system and other massive advantages over your bits of user code. Don't do yourself what something else can already do for you safely. – ThingyWotsit May 24 '17 at 14:16
  • On thing is.. on many non-trivial apps, you don't know where the memory is. Something owns it at that picosecond, but what? Thread A owns it, it's on a queue, it's in a pool, thread B owns it, the OS owns it, it's referenced in a callback.... You can't free it in user code - you just can't, you don't know who or what is using it, so don't try:) – ThingyWotsit May 24 '17 at 14:27
  • @ThingyWotsit: I'm going to be naughty and re-open this question so you can answer. The dupe is not particularly exact anyway, and you add an interesting perspective. Get in quickly though lest it's closed again. – Bathsheba May 24 '17 at 14:41