6 ms·

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 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.
  - joeyo 17y ago
    At the risk of hijacking the thread, since you are coding the same apps on multiple handheld platforms/languages, would you care to comment on which platform you enjoy developing in the most and why?
    - briansmith 17y ago
      If it is possible to do it in Java ME, then Java ME is the best. It is so easy to code for, it is the most widely deployed by far, and it is easy to port to Android and Blackberry. Unfortunately, there are a lot of cases where the user experience with Java ME is sub-optimal to native apps or some capability is exposed only via the native API. Windows Mobile is probably the worst because it has a pretty low market share, it is expensive to get started, and it is pretty tedious to code for. Symbian is the most tedious to code for but it has a huge market share. The iPhone SDK is the only way to make iPhone apps, and the iPhone is obviously very important so you can't ignore it. It was the most expensive to get started for because it more-or-less requires the purchase of a Mac. Android is easy to code for right now but I've heard that the Cupcake update is causing a lot of people pain. When more devices from more manufacturers are released on more carriers, we may find that Android is not much better than Java ME in terms of ease-of-coding.
  - psranga 17y ago
    My comments were about "big" self-contained projects for which it's worth it to have their own internal infrastructure and idioms etc. An example would be a compiler or an interpreter or a web server. For smallish programs like what you describe, I agree that manual memory management can be decent overhead. Many "big" projects try to reduce the memory management hassles by embedding an interpreted language such as Tcl or Lua for implementing non-performance intensive tasks. I'm not advocating writing everything in C++, but with the right tools and in the right circumstances, the benefits of C++ can outweigh the annoyance of manual memory management. Another reason I'm skeptical of garbage collection is because I read that unless you do things in a specific way you can have references hanging around in Java resulting in memory bloat.

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.
- joeyo 17y ago
  At the risk of hijacking the thread, since you are coding the same apps on multiple handheld platforms/languages, would you care to comment on which platform you enjoy developing in the most and why?
  - briansmith 17y ago
    If it is possible to do it in Java ME, then Java ME is the best. It is so easy to code for, it is the most widely deployed by far, and it is easy to port to Android and Blackberry. Unfortunately, there are a lot of cases where the user experience with Java ME is sub-optimal to native apps or some capability is exposed only via the native API. Windows Mobile is probably the worst because it has a pretty low market share, it is expensive to get started, and it is pretty tedious to code for. Symbian is the most tedious to code for but it has a huge market share. The iPhone SDK is the only way to make iPhone apps, and the iPhone is obviously very important so you can't ignore it. It was the most expensive to get started for because it more-or-less requires the purchase of a Mac. Android is easy to code for right now but I've heard that the Cupcake update is causing a lot of people pain. When more devices from more manufacturers are released on more carriers, we may find that Android is not much better than Java ME in terms of ease-of-coding.
- psranga 17y ago
  My comments were about "big" self-contained projects for which it's worth it to have their own internal infrastructure and idioms etc. An example would be a compiler or an interpreter or a web server. For smallish programs like what you describe, I agree that manual memory management can be decent overhead. Many "big" projects try to reduce the memory management hassles by embedding an interpreted language such as Tcl or Lua for implementing non-performance intensive tasks. I'm not advocating writing everything in C++, but with the right tools and in the right circumstances, the benefits of C++ can outweigh the annoyance of manual memory management. Another reason I'm skeptical of garbage collection is because I read that unless you do things in a specific way you can have references hanging around in Java resulting in memory bloat.