6 ms·

"It tends to break horribly as soon as someone does anything unexpected" is usually the argument used against manual memory management.

cperciva 17y ago
No. Using malloc/free will break if your code is broken -- but you look at your code and prove that you're not using memory after it has been freed, not accessing memory locations outside of the allocated regions, and not allocating unbounded amounts of memory, then you have a guarantee that memory management won't cause new problems for you. With garbage collection it's possible to have perfectly correct code which nonetheless breaks horribly as a result of the garbage collector being "smart" in very stupid ways.
- carterschonwald 17y ago
  the tricky bit is that pen and paper proofs break down when managing software level of complexity of that sort, and mechanized theorem proving is tough even with toy examples
  - dinkumthinkum 17y ago
    I don't think he's talking about a formal mathematical proof, rather inspecting the code and understanding it thoroughly such that you can show, without the Pumping Lemma or anything like that, that memory access is being done properly.
    - nostrademons 17y ago
      ...which is also exceptionally difficult. Yeah, there're tricks you can use to make it easier, like RAII and thoroughly documenting ownership of parameters. But once you get past a few tens of thousands of lines, written by more than one programmer, it becomes essentially impossible to understand it thoroughly enough that you can tell by inspection whether it'll leak memory.
- briansmith 17y ago
  You make that proof sound easy. In reality, proving that code is correct is one of the most difficult things that a programmer can be tasked with. And, even if you could program is correct, somebody could make a small change--even a single character--and invalidate your whole proof. That is the primary reason garbage collection exists.
  - psranga 17y ago
    If we interpret what cperciva said to mean 100% correct proofs you're correct. But you can do a lot of things in C++ to avoid memory leaks/reading from freed memory etc. Some of them are: 1) are auto-freeing templatized heap object class (the compiler will automatically call destructor when objects goes out of scope, call free in the destructor). 2) Overload free/delete to fill up freed memory with 0xdeadbeef etc so that code that reads from there is likely to crash due to invalid data. 3) Use one of the non-libc memory managers which will track memory allocs and frees and tell at exit if all memory was freed. Some will even have tricks to tell you which allocation was not freed. 4) If all else fails, use Valgrind for the really tough ones. Coupled with a good regression/unit test suite, memory leak tracking will be an insignificant part of your development effort.
    - briansmith 17y ago
      I am building a set of cross-platform mobile applications. In order to get the application working on as many devices as possible, I am writing the same programs multiple times: in C++ (Windows Mobile & Symbian flavor), in Java (ME, Android, and Blackberry flavors), in Objective-C (iPhone flavor), and in one case even Flash. These are all different implementations of the exact same program written by the same programmer who has more than 10 years of exposure to Java and C++. Without a doubt, the #1 biggest waste of time in coding the application is the manual memory management required in C++. Symbian C++ is particularly horrible, but the memory management still sucks even when I get to write "standard" C++. And, it sucks right from the beginning (which kind of smart pointer do I need here?) through the middle (does this API call take over ownership of this pointer or not?) all the way through the end (am I sure I got it all correct before I pay for this $200 signature?). I can take some shortcuts in the C++ versions because they have more memory to work with than the Java versions, but still the memory management is a much bigger hassle in the C++ versions than in the Java versions.
- s3graham 17y ago
  > then you have a guarantee that memory management won't cause new problems for you. Bah. Your original comment was that GC became too slow, not that it didn't work correctly. Using malloc/free, you're dependent upon the system allocator, and so you have no time or space overhead guarantees from the allocator. Chaining free coalesce, OS paging, etc. can easily make you miss a soft-realtime deadline, make your UI pause, etc.
biohacker42 17y ago
You're both right! Obviously manual memory management is very dangerous and straight up not for the average programmer. But if you look thorough GC code by great hackers. You'll notice a style that looks almost like free/malloc in that they take deliberate care to make life easy for the GC. And on the other hand, programmers who are completely oblivious to how memory works, often write code which can confuse even the best GC so much that you essentially end up with a big memory leak. Strictly speaking the memory isn't leaking, the GC just can't quite dare clean it up. The lesson is, even the best VM and GC won't make bad programmers into good ones.

cperciva 17y ago

No. Using malloc/free will break if your code is broken -- but you look at your code and prove that you're not using memory after it has been freed, not accessing memory locations outside of the allocated regions, and not allocating unbounded amounts of memory, then you have a guarantee that memory management won't cause new problems for you. With garbage collection it's possible to have perfectly correct code which nonetheless breaks horribly as a result of the garbage collector being "smart" in very stupid ways.

carterschonwald 17y ago
the tricky bit is that pen and paper proofs break down when managing software level of complexity of that sort, and mechanized theorem proving is tough even with toy examples
- dinkumthinkum 17y ago
  I don't think he's talking about a formal mathematical proof, rather inspecting the code and understanding it thoroughly such that you can show, without the Pumping Lemma or anything like that, that memory access is being done properly.
  - nostrademons 17y ago
    ...which is also exceptionally difficult. Yeah, there're tricks you can use to make it easier, like RAII and thoroughly documenting ownership of parameters. But once you get past a few tens of thousands of lines, written by more than one programmer, it becomes essentially impossible to understand it thoroughly enough that you can tell by inspection whether it'll leak memory.
briansmith 17y ago
You make that proof sound easy. In reality, proving that code is correct is one of the most difficult things that a programmer can be tasked with. And, even if you could program is correct, somebody could make a small change--even a single character--and invalidate your whole proof. That is the primary reason garbage collection exists.
- psranga 17y ago
  If we interpret what cperciva said to mean 100% correct proofs you're correct. But you can do a lot of things in C++ to avoid memory leaks/reading from freed memory etc. Some of them are: 1) are auto-freeing templatized heap object class (the compiler will automatically call destructor when objects goes out of scope, call free in the destructor). 2) Overload free/delete to fill up freed memory with 0xdeadbeef etc so that code that reads from there is likely to crash due to invalid data. 3) Use one of the non-libc memory managers which will track memory allocs and frees and tell at exit if all memory was freed. Some will even have tricks to tell you which allocation was not freed. 4) If all else fails, use Valgrind for the really tough ones. Coupled with a good regression/unit test suite, memory leak tracking will be an insignificant part of your development effort.
  - briansmith 17y ago
    I am building a set of cross-platform mobile applications. In order to get the application working on as many devices as possible, I am writing the same programs multiple times: in C++ (Windows Mobile & Symbian flavor), in Java (ME, Android, and Blackberry flavors), in Objective-C (iPhone flavor), and in one case even Flash. These are all different implementations of the exact same program written by the same programmer who has more than 10 years of exposure to Java and C++. Without a doubt, the #1 biggest waste of time in coding the application is the manual memory management required in C++. Symbian C++ is particularly horrible, but the memory management still sucks even when I get to write "standard" C++. And, it sucks right from the beginning (which kind of smart pointer do I need here?) through the middle (does this API call take over ownership of this pointer or not?) all the way through the end (am I sure I got it all correct before I pay for this $200 signature?). I can take some shortcuts in the C++ versions because they have more memory to work with than the Java versions, but still the memory management is a much bigger hassle in the C++ versions than in the Java versions.
s3graham 17y ago
> then you have a guarantee that memory management won't cause new problems for you. Bah. Your original comment was that GC became too slow, not that it didn't work correctly. Using malloc/free, you're dependent upon the system allocator, and so you have no time or space overhead guarantees from the allocator. Chaining free coalesce, OS paging, etc. can easily make you miss a soft-realtime deadline, make your UI pause, etc.

biohacker42 17y ago

You're both right! Obviously manual memory management is very dangerous and straight up not for the average programmer. But if you look thorough GC code by great hackers. You'll notice a style that looks almost like free/malloc in that they take deliberate care to make life easy for the GC. And on the other hand, programmers who are completely oblivious to how memory works, often write code which can confuse even the best GC so much that you essentially end up with a big memory leak. Strictly speaking the memory isn't leaking, the GC just can't quite dare clean it up. The lesson is, even the best VM and GC won't make bad programmers into good ones.