Re: copy contructor



Eric Schwartz (emschwar@xxxxxxxxx) wrote on MMMMCCCXLIV September
MCMXCIII in <URL:news:etomzoexs9u.fsf@xxxxxxxxxxxxxxx>:
"" Abigail <abigail@xxxxxxxxxx> writes:
"" > That's one way, but I don't like that (too much typing, and I prefer
"" > to avoid using literal strings for hash keys - using lexical variables
"" > gives you all the power 'use strict' can give you). I do it this way:
"" >
"" > package Sick::Snake; {
"" >
"" > use Scalar::Util qw 'refaddr';
"" > our @ISA = qw /Angry::Snake/;
"" >
"" > my %shivering;
"" > my %sneezing;
""
"" I suppose the only concern I had was that if you have a number of
"" attributes for an object, this list might become wearying itself to
"" type. But then, I suppose you only have to do so once, and anyhow, a
"" nice comment block to alert the reader that these were attributes
"" would work fine. It just reminds me of a project I once worked on
"" where there was a data structure with literally dozens of parallel
"" arrays (poorly designed, I'll concede), and it was often hard to track
"" modifications so that they tracked each of these.
""
"" > sub DESTROY {
"" > my $snake = shift;
"" > delete $shivering {refaddr $snake};
"" > delete $sneezing {refaddr $snake};
"" > }
""
"" Here in particular, if you aren't careful, you might add an attribute
"" and forget to put it in DESTROY, whereas my approach would look like:

If you are afraid you forget it, either use Class::Std (and then you
won't even have to create a DESTROY function), or do something like:

my @attrs = \my (%shivering, %sneezing, ...);

sub DESTROY {
my $snake = shift;
delete $$_ {refaddr $snake} for @attr;
}

"" sub DESTROY {
"" my $snake = shift;
"" delete $attrs{refaddr $snake};
"" }
""
"" But your arguments for lexicals giving the equivalent of use strict is
"" a strong one, and I don't suppose it's an undue burden to remember to
"" add a new attribute to DESTROY. Anyhow, even if you forget, the worst
"" that would happen is you hold a reference that is inaccessible-- a
"" memory leak, but not a critical program failure in itself.


No, the memory leak isn't the worst problem. That's indeed a minor problem.
Not cleaning up attributes has the potential for a program failure though.
Inside-Out object work because every the memory address of every reference
is unique - but the addresses are only unique for the currently existing
references. If a reference goes out of scope (or rather, the thing it
points to), the memory may be reused, and a new reference might have the
same address as an old one. If you don't clean up your attributes, new
objects may inherit attributes from old, retired, objects.



Abigail
--
perl -e '* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
/ / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / / /
% % % % % % % % % % % % % % % % % % % % % % % % % % % % % % % %;
BEGIN {% % = ($ _ = " " => print "Just Another Perl Hacker\n")}'
.



Relevant Pages

  • Re: Looping-related Memory Leak
    ... memory leak / balloon for reasons I cannot figure out. ... end of the loop. ... reference count never reaches zero, and they remain alive until the ... the generational collector doesn't break cycles that involve ...
    (comp.lang.python)
  • Event handling, DOM, closures and memory leaks (again)
    ... But I needed to store DOM elements and can't solve it ... method solution to cleanup memory leak problems. ... return handler; ... creating a circular reference. ...
    (comp.lang.javascript)
  • Re: does python have useless destructors?
    ... >> between disposing at the end of the function or when some containing ... and in CPython that happens at the moment the last reference is ... C Python destroys an object when no references are left. ... IronPython destroy objects when the underlying garbage collector feels like ...
    (comp.lang.python)
  • Re: Application crashes on handled error. Why?
    ... but terminate events on those objects are not fired. ... call no more than one method and destroy immediately. ... >> I am not too happy about zapping a reference to a Parent in a Child ...
    (microsoft.public.vb.general.discussion)
  • Re: Memory leak in ruby code
    ... a method that cleared the reference. ... No different to a memory leak in a non-garbage collected language. ... static data member or in a dynamic data member (instance ... obj could be reclaimed after doSomeWork(assuming the stack ref is the ...
    (comp.lang.ruby)