Re: Confused about gcnew and object lifetime

Chris Edgington wrote:

As a side note - this almost seems like it would have the tendency to
create "sloppy" programmers - allocating objects willy nilly, depending
on the system to clean up.

In a system that was designed to handle that it's OK. It's a different story when those programmers later go to an unmanaged environment, whether they can adapt.

But even in the managed world, there are two issues with this "the system will clean up for me" attitude. First, resources still need to be manually disposed. Being sloppy there means scarce system resources may remain locked indefinitely. Not closing a file is often not such a big problem, but not closing a mutex is disastrous. IMO, it's not immediately clear which object is a resource, and it puts an extra pressure on the programmer. There's no quick way that I know of telling whether an object needs deterministic destruction or not. GC makes programmers sloppy in a way that they no longer care and may not even deallocate resource type objects. This is a much bigger problem, as far as I can tell, than being sloppy with memory allocations. In fact, in ..NET you can't deallocate memory, only the system can, but you still MUST deallocate resources. In native C++ there is stack syntax that always works, and boost::shared_ptr that always guards everything properly. Ironically, .NET makes you think even harder than a C programmer, because for every object allocated you have to look up the help to decide whether it needs to be deleted or not. It makes me paranoid -- did I miss something that really needs destruction? What happens if a class doesn't store any resources today, but it may in the future? That class will be used in 100s of places, without the proper deallocation. Later a resource will be added for that class, and all of a sudden every existing code becomes invalid. So classes that MAY behave as a resoruce should be designed to be a resource from day 1. These issues make you think just as hard as if you didn't have GC.

What's even worse is that .NET doens't have all the tools to make guaranteed proper deletion of resources. The unmanaged world has slowly evolved during the past several decades, and we finally have reference counted smart pointers and deterministic destruction with very solid guarantees and strong, stable libraries that really makes you forget about manual deletion of everything. .NET was designed with the goal that you no longer have to care about any of this stuff, which is not entirely true. Maybe 99% of your objects never need to be deleted, but that remaining 1% is as critical as ever was. So programmers still have to be alert.

The second (completely different) aspect is that just because all memory is guaranteed to be deleted it doesn't mean you can't have leaks anymore. You can still have serious memory leaks even if all your objects are always deterministically destructed. It's as simple as forgetting about your items stored in containers. You no longer need them, but they may still reside in some collection in the memory. If you forget about removing unused objects from lists, maps, sets, hashed storages, they occupy precious memory, and it's virtually the same effect as a memory leak. Even worse, no memory leak detector ever finds that. These kinds of problems are not automatically solved by any type of garbage collection or reference counting. There's no magic solution that enitrely protects the system from sloppy programmers.

Once I had a huge lookup table to speed up calculations, and I forgot to make it a static member. So every instance of my classes had its own copy of the table, and systems with 256MB RAM ran out of memory quickly. No leak detector found anything, and yet my application's memory consumption was growing well beyond the expected limits. Once again, there was nothing that didn't get properly freed, and yet I had memory issues due to a human error.

Tom
.

Relevant Pages

  • Re: OOP and memory management
    ... >> The are more resources that a single program must manage ... >> new programmers just means that they never get any experience ... >> all memory allocated must be deallocated. ... Read above where I said that the language ...
    (comp.programming)
  • Re: REGION=0M and LSQA
    ... At the time, memory was very expensive, and we ... remaining storage and always issued a return code zero. ... programs actually worked in production, ... all of the resources used by the job up until that point ...
    (bit.listserv.ibm-main)
  • Re: Determine calling function
    ... to encourage programmers to escape from following dogma mindlessly. ... ad absurdem of an insistence on checking malloc(), ... I don't know how much memory starting at ... Obviously a *hard* setrlimit() cannot be employed for throttling ...
    (comp.lang.c)
  • Re: A realistic price comparison
    ... > Spreading Apple FUD is just as bad as spreading Microsoft FUD. ... > However, I assure you, I had more than enough resources on my XP ... > instilled in them by having limited memory and disk space early on. ...
    (comp.sys.mac.advocacy)
  • Re: Alternatives to C: ObjectPascal, Eiffel, Ada or Modula-3?
    ... pretty much have memory bugs, ... having to do manual cleanups for 100% of your resources or for only 1%? ... This is a slight problem in languages like Java that have GC but no flow-control abstraction. ... Languages like Lisp and Smalltalk are another story: it's easy to have a with-open flow control construct that runs some subordinate code and then cleans up, and to have this be the standard way to use such things. ...
    (comp.programming)
Loading