161–170 of 175 posts
I've got an idea... We have a counter that goes up by 1 every time you call malloc. And down by one every time you call free. And when the program quits, if the counter isn't zero, an email is fired off and a dollar gets sent from the developers bank account to the users bank account...
Isn’t that close to how ARC (automatic reference counting) works?
This solution doesn't do anything to prevent leaking memory in anything but the most pedantic sense, and actually creates leaks and dangling pointers. The function just indirects malloc with a wrapper so that all of the memory is traversable by the "bigbucket" structure. Memory is still leaked in the sense that any unfreed data will continue to consume heap memory and will still be inaccessible to the code unless the…
This is the core idea: > It is [...] entirely optional to call free. If you don’t call free, memory usage will increase over time, but technically, it’s not a leak. As an optimization, you may choose to call free to reduce memory, but again, strictly optional. This is beautiful! Unless your program is long-running, there's no point of ever calling free in your C programs. The system will free the memory for you when…
Reminds me of the HFT shop that built in Java and simply turned the garbage collector off. Then when the market closed they would restart the process for the next day.
Obviously this is a joke, but the real message should be: if you can't manage your own memory, you should be using a language implementation with automatic memory management. If your code really needs to run "close to the metal", you really need to figure out how to manage your memory. In 2024, language implementations without automatic memory management should be reserved for applications that absolutely need them.
> if you can't manage your own memory, you should be using a language implementation with automatic memory management. I agree, and would expand the idea to all kinds of resources (files for example). Sadly not many languages have "automatic resource management". For example Go has automatic memory management, but if you read an HTTP request's body you have to remember to call req.Body.Close(). If you open a file you…
VB Classic has reference counting and the terminate event is fired when the count goes to zero. So as long as you don't store the reference in a global the terminate event is guaranteed to run when it goes out of scope (so long as you don't have circular references of course).
C++ has Resource acquisition is initialization (RAII)
Earlier quoted context omitted.
The difference is that if you're writing a program you know the scope of use of all libraries, whether they be externally loaded or internal abstraction boundaries, and also know the scope of use of the program, and can make a call as to whether cleanup during opetation is required.
Not really. In theory you can, but in practice there are parts written by a different team and you don't know the scope of there parts. I also know someone who maintains some Clinton era encryption. that code is controlled who can know about it as obsecurity was all you were allowed. There are other pathalogical cases where you can't know everything about your program-
Extending something you did not originally write may be quite different, of course.
Earlier quoted context omitted.
> It obviously is a joke, but at the same time it's actually a viable approach for the right problem. Define "it" here. Because "just don't free" is pretty different from what's in the post!
Yes. Hence the word 'joke' I used. For short running programs, it's fine. The longer running programs you can often find a few places where 95% of the leaks happen and easily 'free' those leaving the last 5% to leak slowly. It depends. Just remember it's a valid solution sometimes.
The joke and the sometimes valid solution are different strategies.
The joke only reminds people of the valid solution. It feels like multiple people are giving the article the briefest skim and assuming the two are the same. Perhaps focusing on the words "optional to call free" and extrapolating off that without looking at the code or properly reading the rest of the text.
Unless I'm badly missing something?