On Sep 30, 9:36 am, Carl Jokl <[email protected]> wrote: > The way I see it is that even with the Computer Science background and > understanding O/S memory allocation models and how C/C++ allocates > memory as well as Stack and Heap memory theory the errors still happen > because I am human and miss things sometimes. It is all good and well > when the program flow is simple enough for the allocations and > deallocations to be easy to see and in a straightforward logic. The > more complex the application gets the more complicated it becomes to > manage the memory correctly. Both feeing memory which something is > still using or not freeing it leads to problems.
I started reading (maybe I should get the whole thing) a whole book on Kindle about "Memory as a Programming Concept in C and C++". Like you've pointed out, the problem in complex applications is knowing when it's OK to free something, especially since the consequences of freeing something prematurely are disastrous (usually a crash). Since so many people work with C and C++, there are standard solutions, such as reference-counting, but these introduce their own complexities. For a lot of people, garbage collection hits a sweet spot: pretty easy to get right, not too expensive in terms of memory or CPU. > Maybe I should try Assembler just for kicks....I like pain. Doing anything radically outside your comfort zone will help you think more flexibly -- that was one of Dick's points in the other thread. Assembly will let you think more concretely about the interaction of the CPU and RAM. Most people are headed in the other direction, adding more layers of abstraction. I think it's helpful to have spent at least a little time right on the iron. --Chris -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
