in reply to Tracing zombie variables.

UPDATE:

I didnt notice your comment about OO when i first wrote this, so im comenting now. Your concern about OO is unfounded. The overhead to which you refer is a consequence of method call look up. In the case I proposed this is not really a factor as the only method calls that I suggest you support is new() and DESTROY() and they only get called once per object and thus the overhead is negligable.

END UPDATE

Well, there arent really any good ways to do this. However one trick that you may find useful (assuming you are doing OO and that your nodes are discrete objects) is to keep track of the number of created nodes and the number of destroyed nodes, like so 

package LL::Node;
{
  my $allocated=0
  sub new {
    $allocated++;
    bless {},$_[0];
  }
  sub DESTROY {
    $allocated--;
  }
  sub END {
    warn "There were $allocated nodes that have not been properly free
+d dusing destruction.\n"
     if $allocated;
  }
}
# other stuff

[download]
This way you will at least know how many objects with cyclic references that havent been freed. Of course you could just use the DESTROY sub to ensure that any links are broken 
sub DESTROY {
  $allocated--;
  $_[0]->{next}=undef;
  $_[0]->{prev}=undef;
}

[download]
Assuming of course that you are using hash based nodes...

Also if you wanted to get into really deep mojo you could use Scalar::Util which provides a way to make a "weak" reference, but personally i wouldnt do that...

HTH

Yves / DeMerphq
---
Software Engineering is Programming when you can't. -- E. W. Dijkstra (RIP)

Replies are listed 'Best First'.
Re: Re: Tracing zombie variables.
by ash (Monk) on Aug 29, 2002 at 12:59 UTC

      > In the case I proposed this is not really a factor as the
      > only method calls that I suggest you support is new() and
      > DESTROY() and they only get called once per object and
      > thus the overhead is negligable.

    You're indeed right demerphq.
    I was blinded by the method explained in Mastering Algorithms with Perl
    which has methods for next() and prev().

    Thank you for enlightenment.

    -- 
    Ash/asksh <ask@unixmonks.net>

[reply]
[d/l]
[select]
      s blinded by the method explained in Mastering Algorithms with Perl which has methods for next() and prev().

      And rightly so. You _should_ supply such methods. If there is any chance that someone outside of your module will need to access these methods/attributes then you should provide a method interface for them to do so.

      However inside of your module, the one that manipulates the actual data structure, you can certainly make the design decision to use the underlying object implementation. After all it is your code and your implementation so the only one that you can burn is yourself.

      For instance I completely bypass the method interface for my node objects in my Treap implementation. However my node is a subclass of a Class::Struct so that anything outside can have something more stable to utilize. (ie no nasty suprises for users that use the method interface).

      Yves / DeMerphq
      ---
      Software Engineering is Programming when you can't. -- E. W. Dijkstra (RIP)

[reply]

In Section Seekers of Perl Wisdom