Re: Proper pointer cleanup question [message #34656 is a reply to message #34655] |
Tue, 08 April 2003 12:11   |
David Fanning
Messages: 11724 Registered: August 2001
|
Senior Member |
|
|
Tom McGlynn (tam@lheapop.gsfc.nasa.gov) writes:
> I'm curious why you associate this with IDL's weak typing
> (or is it just that that's another avenue for making
> mistakes in IDL). Perl would reclaim memory even
> though it's also weakly typed.
PERL must be the software of choice then for all
important programming projects. :-)
I was just making a point that it is easy to leak
memory if you turn a pointer variable into some
other kind of variable without de-allocating the
pointer memory. Perhaps RSI could put a check in
the code to have a quick look to see if the variable
that is being re-defined is a pointer (or object, or
something that *contains* pointers or objects, etc.,
etc.), but my guess is this would slow IDL down so
much we would have all kinds of people complaining
that their prayers were answered, again.
But really, pointers and objects are SUPPOSE to
persist over time. That is the whole point of them.
How could IDL possibly know if you are *really* done
with them? You should tell IDL by freeing them
explicitly. I believe this is something that is
covered in Programming 101, if I'm not mistaken.
(And, anyway, IDL has already done us a favor
by having the *things* pointers point at act like
regular IDL variables. That's a nice touch and gives
us a lot more free time during the day to read a book
rather than free up pointers.)
> On a slightly different tack.... Is this situation where
> users need to explicitly deallocate memory now something
> that is mandated for all future versions?
Uh, yes.
> Or could IDL
> implement garbage collection in the future?
They could. I'd bet all of last month's salary (very,
very little, unfortunately) that they won't. It would
be so costly in terms of time everyone would complain.
Perhaps when quantum computers are in vogue.
> Garbage collection seems like the kind of detail that languages at
> IDL's level should take care of automatically.
I'm not sure what "level" IDL is on (and neither does
RSI, to judge from the disconnect between language features
and the people that they are trying to sell it to), but
a language that handles this automatically will be a slow
language indeed.
> I hope
> RSI doesn't think it's now precluded by considerations
> of backwards compatibility. I don't think there's any problem
> with explicit deallocations, but I could imagine someone building
> programs that depend upon the existence of allocated but
> unassociated memory. [Though I can't imagine why!]
In my experience people build all *kinds* of programs. Most
of them leave me shaking my head, to be honest. :-)
Cheers,
David
--
David W. Fanning, Ph.D.
Fanning Software Consulting, Inc.
Phone: 970-221-0438, E-mail: david@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|