On Monday 05 January 2004 3:12 pm, Rob Dixon wrote: > Gary Stainburn wrote: [snip] > > sufficient, or will this still tie up memory? Is there a better way? > > Hi Gary. > > We really need to see your 'delete' and 'DESTROY' methods. But you can get > around the problem by setting $T1 to anything that's not a reference to the > object. At present you're setting it to the result of your 'delete' method, > but you could equally write > > $T1 = 99; > or > undef $T1; > > Alternatively you could let $T1 go out of scope (at the end of a block) > and be implcitly deleted itself by Perl. That only works if it's a 'my' > variable. > > HTH, > > Rob
Hi Rob, I'm pretty okay with the $T1 going out of scope, and being re-assigned, hence the difference between my two examples. The question was more academic, trying to cover my back in the case of bad programming, where a ref remained by mistake. An unlikely event with the way Perl scoping works. I was really looking to see if there was a way of effectively zeroising the refcount for the object, this FORCing the garbage collector to free the memory. The best I've come up with is to call DESTROY from within the delete method, and from within there deleting all the elements in the hash and undefining the scalar holding the hashref. The way I see this, the worst that would happen is that a single scalar and the BLESS info associated with it would remain. However, as I said, it's very unlikely to happen, so I don't think it's worth worrying about too much. I'm thinking of mountains and mole-hills now. -- Gary Stainburn This email does not contain private or confidential material as it may be snooped on by interested government parties for unknown and undisclosed purposes - Regulation of Investigatory Powers Act, 2000 -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] <http://learn.perl.org/> <http://learn.perl.org/first-response>
