Give me five reasons why I should free() when the OS will reclaim the memory anyways or I kill this anime blob.

Give me five reasons why I should free() when the OS will reclaim the memory anyways or I kill this anime blob.

The Kind of Tired That Sleep Won’t Fix Shirt $21.68

Black Rifle Cuck Company, Conservative Humor Shirt $21.68

The Kind of Tired That Sleep Won’t Fix Shirt $21.68

  1. 2 years ago
    Anonymous

    It's a good practice.

    • 2 years ago
      Anonymous

      your program will have to die before the memory is reclaimed you stupid Black person
      it's like asking why you should clean your own room when it won't matter after you blow your brains out

      Not five reasons

      • 2 years ago
        Anonymous

        >black bullets
        why?

        • 2 years ago
          Anonymous

          whyte wimminz love da big black cartridge

      • 2 years ago
        Anonymous

        >when the OS will reclaim the memory anyways
        via the OOM killer? I think your admins will kill you first.

        NYPA.

  2. 2 years ago
    Anonymous

    americans really love gun violence eh

  3. 2 years ago
    Anonymous

    Not freeing is a viable strategy for short lived processes. This is often actually done e.g. in compilers.

    • 2 years ago
      Anonymous

      Sounds more like your compiler is shit.

      • 2 years ago
        Anonymous

        I see memory leaks when I run gcc through valgrind

        • 2 years ago
          Anonymous

          show screenshot of supposed memory leaks

  4. 2 years ago
    Anonymous

    your program will have to die before the memory is reclaimed you stupid Black person
    it's like asking why you should clean your own room when it won't matter after you blow your brains out

  5. 2 years ago
    Anonymous

    - OS may not reclaim memory on process exit (on modern OSes, happens with shared memory)
    - if it does, then it's still memory that could have been used for something else
    - you may run out of memory before execution completes, and the OS will kill your process
    - it may keep the pages mapped in process memory, making future allocations faster
    - in multithreaded environments, concurrent allocation and de-allocation operations can be optimized to complete faster

  6. 2 years ago
    Anonymous

    Can I eat the remains?

  7. 2 years ago
    Anonymous

    Here you go, moron.

    https://en.m.wikipedia.org/wiki/Memory_leak#Consequences

    https://en.m.wikipedia.org/wiki/Memory_leak#Effects

  8. 2 years ago
    Anonymous

    Just never free(). See what happens. Remember to mention "btw I never free()" in CV and during interviews. Remove yourself from the workforce.

  9. 2 years ago
    Anonymous

    it's okay, bro, just run this code

    • 2 years ago
      Anonymous

      Frick i forgot the pic

  10. 2 years ago
    Anonymous

    >five reasons
    imposible, anyway...

    good pratice
    you can develop a bad habit if not used
    crashes on atexit
    [filler space]
    bad for shared resources

  11. 2 years ago
    Anonymous

    Viruses can steal ur bits

  12. 2 years ago
    Anonymous

    The OS won't reclaim the memory until after the program is done with it, which happens when it's freed or when the program exists.
    The OS, compiler or anything else can't compensate for shit code.

  13. 2 years ago
    Anonymous

    You shouldn't. Programs run faster with allocate&forget (given you exit early enough).
    It's also a good reason to use GC; you get the speedup but the program doesn't crash horribly if memory runs out.

Your email address will not be published. Required fields are marked *