Re: events and object lifetime

Nick Hounsome wrote:
The only problem with using IDisposable in this case is that it
violates a design rule for .NET, which is that it's never _necessary_
to call Dispose() in order to free an object.

I only say IDisposable because it has extra language support.
You could use any method.

.... and you would be faced with the same problem.

You are not violating a design rule about resources anymore than if you held
onto the objects with a direct reference and had a method to set the
reference to null.

Not true except for static references. If you held a direct reference
to the objects, then they would be collected when that reference were
to go out of scope. Static references, of course, never go out of
scope.

The point is still that you would have make a conscious effort to _do_
something in order that the object(s) be collected. The design ideal in
..NET is that simply having things go out of scope causes them to be
collected. Whether you use Dispose() or some other method name, you're
still left in the position of having to take some explicit action to
free the objects for collection which, if you fail to take it, leaves
them allocated for the lifetime of the running application, which is
probably not what you intended.

No - true memory leaks are impossible in .NET - the objects are accessible
through the ItemDeleted event and hence are not leaks.

Sorry. I fail to see the difference between an object that is left
hanging around until your application terminates and a "true" memory
leak. If I have a 24 x 7 application, and it continues to eat more and
more memory until it finally exhausts my system's VM and crashes, and
someone were to cheerfully point out, "But it's not a _true_ memory
leak!" I would thump them. :) Stuff that (inexplicably) doesn't get
garbage collected is a memory leak, regardless of the mechanism at work
and the level of abstraction.

What I mean by "level of abstraction" is that at a very low level of
abstraction you are correct: the objects are still accessible using
some little-known features of .NET. However, from the level of
abstraction of my program, the objects have gone out of scope but will
never be GC'd. From that point of view, it's a leak.

Weak references are a time/space trade off, no more and no less.

Not true. Weak references allow you to leave object disposal to the
garbage collector and concentrate on programming your application.
Using IDisposable, or some other disposal mechanism, requires that you
do proper memory housekeeping in order to avoid leaks (or, if you
prefer, "stuff not being garbage collected," which I maintain is
essentially the same thing). Weak references allow you to think about
static event subscribers in the same way you think about other objects
in your program: when they go out of scope, they "go away" (sooner or
later) and the memory they occupy is freed for reuse. Requiring
explicit disposal requires that you think about static event
subscribers differently: "This subscribes to a static event so I have
to explicitly dispose of it or it won't be GC'd."

Weak reference delegates allow you to decide whether subscribing to a
certain event "counts" for purposes of garbage collection. My Weak
Reference event handler wrappers allow you to express something that
native C# doesn't allow you to express (but I wish that it did): "I
want to subscribe to this event, but this subscription isn't so
important that it should keep me alive." You make your wishes known in
that regard at the moment of event subscription, and then never worry
about it again.

If you go the Dispose() route, then you have to make your wishes known
at the moment the subscribing object is no longer needed, which may not
be all that easy to determine. It leads you into strategies like
reference counting, which leads back to... C++ and manual memory
management, which flies in the face of C#'s set-it-and-forget-it,
garbage-collected mindset.

That, to me, far outweighs the time / space aspects.

.

Relevant Pages

  • Re: Memory Cleanup
    ... Calling GC.Collect is not the ... // The total memory has not gone down. ... reference counters, and nothing happens when objects go out of scope. ... objects just remain in memory waiting for the garbage collector to remove ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: FileStream.Close() & GarbageCollection - Memory Leak Question
    ... Somewhere in memory the memory allocated to the object still resides, ... If you don't clear the variable, then yes, this will throw an exception. ... concerned the GarbageCollector uses the reference and by nulling it I ... It is on the other hand the lack of live references to allocated memory that the garbage collector figures out what to collect. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Script mysteriously stops executing...
    ... memory leaks...that seems to be the case. ... Standard PHP does not have a garbage collector per se - ... These are for the cyclic reference garbage collector - this is a far ...
    (comp.lang.php)
  • Re: A re-announce on GCs defects
    ... It's bad for CPU/Resource intensive but memory cheap objects. ... There may be more than one strong references and you don't know when and where to call Dispose. ... Instead of calling the destructor you call Dispose if the reference counter is 0. ... Note GC in java and C# is not really an addictive as someone would argue since there is no way to do real memory management like delete obj in C++. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: How much do you leave to VB.Net GARBAGE COLLECTION???
    ... The first time that is checked if it can be destructed is as you invoke the method dispose as that is a member of the object or a member of its parent class. ... Not fysical direct, as one of the goals is that the GC does its work as it is needed in a kind of batch, to get the highest real performance, which is of course not when there is/are more then enough memory and resources available. ... Setting something to nothing means that you set the reference of the object to nothing. ... Dim myObject as New Object ...
    (microsoft.public.dotnet.languages.vb)
Loading