All this being said, I don't know if it's fair to compare the approach mentioned in your link with "classical" manual memory management. How often do you see this kind of (de-)allocation patterns in a standard app? Wouldn't a programmer often write "less than ideal" de-allocation code? (honest question there, I sadly never had the opportunity to write in a language with manual memory-management)
You're on the right track, but with a twist: Explicit memory management works the opposite way around. Freeing an object when it goes out of scope, like the paper's oracle, is the worst case scenario. A real programmer is free to optimize and release memory before that, even if the object still has references.
In practice, I doubt the difference matters. The primary focus of memory management in C/C++ is avoiding leaks from objects that were never freed and can never be freed because all their references are out-of-scope. Programmers have a small window to free memory, before the pointers are out of scope, but only once the object isn't needed. There's not much room for optimization.
Comments
You can download the paper from http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.61....
All this being said, I don't know if it's fair to compare the approach mentioned in your link with "classical" manual memory management. How often do you see this kind of (de-)allocation patterns in a standard app? Wouldn't a programmer often write "less than ideal" de-allocation code? (honest question there, I sadly never had the opportunity to write in a language with manual memory-management)
You're on the right track, but with a twist: Explicit memory management works the opposite way around. Freeing an object when it goes out of scope, like the paper's oracle, is the worst case scenario. A real programmer is free to optimize and release memory before that, even if the object still has references.
In practice, I doubt the difference matters. The primary focus of memory management in C/C++ is avoiding leaks from objects that were never freed and can never be freed because all their references are out-of-scope. Programmers have a small window to free memory, before the pointers are out of scope, but only once the object isn't needed. There's not much room for optimization.