| Do we need PTR_FREE anymore? [message #71928] |
Wed, 28 July 2010 18:23  |
wlandsman
Messages: 743
Registered: June 2000
|
Senior Member |
|
|
I am trying to come to terms with the automatic garbage collection
implemented in IDL 8.0. Does this mean that we never have to
cleanup our pointer variables with PTR_FREE anymore? I find this a
little unsettling -- like being told that there is no longer any need
to brush your teeth.
The help files give one obscure example where automatic garbage
collection fails -- when "two objects or pointers refer to each other,
but no other object or pointer refers to either". Is there ever
any other reason (e.g. performance issues) to explicitly call PTR_FREE
anymore?
--Wayne
|
|
|
|
| Re: Do we need PTR_FREE anymore? [message #71983 is a reply to message #71928] |
Fri, 30 July 2010 12:12  |
Adam Lefkoff
Messages: 3
Registered: July 2010
|
Junior Member |
|
|
On 7/30/2010 11:29 AM, Michael Galloy wrote:
> On 7/30/10 11:07 am, James wrote:
>> Wlandsman, that example doesn't sound particularly obscure to me -- it
>> seems like it could come up frequently when dealing with linked data
>> structures.
>>
>> It's a little unusual that IDL has added garbage collection but kept
>> manual memory management intact. Most languages only offer one or the
>> other. It's pretty unusual for a language as high-level as IDL to
>> have manual memory management at all.
>
> But IDL has to continue to support manual memory management or else
> break backward compatibility. I would imagine that PTR_FREE and
> OBJ_DESTROY will be around for a long time.
>
> Mike
HANDLE_FREE still works too!
|
|
|
|
| Re: Do we need PTR_FREE anymore? [message #71988 is a reply to message #71928] |
Fri, 30 July 2010 10:29 |
wlandsman
Messages: 743
Registered: June 2000
|
Senior Member |
|
|
On Jul 30, 1:07 pm, James <donje...@gmail.com> wrote:
> Wlandsman, that example doesn't sound particularly obscure to me -- it
> seems like it could come up frequently when dealing with linked data
> structures.
I notice that early versions of Python had the same limitation, but
since 2.2 (I think) it can handle the case where 2 pointers reference
each other.
>
> It's a little unusual that IDL has added garbage collection but kept
> manual memory management intact. Most languages only offer one or the
> other. It's pretty unusual for a language as high-level as IDL to
> have manual memory management at all.
The manual memory management was introduced back in 1997, and they
seem to have made a strong effort to keep backwards compatibility. --
Wayne
|
|
|
|
| Re: Do we need PTR_FREE anymore? [message #71989 is a reply to message #71928] |
Fri, 30 July 2010 10:29 |
Michael Galloy
Messages: 1114
Registered: April 2006
|
Senior Member |
|
|
On 7/30/10 11:07 am, James wrote:
> Wlandsman, that example doesn't sound particularly obscure to me -- it
> seems like it could come up frequently when dealing with linked data
> structures.
>
> It's a little unusual that IDL has added garbage collection but kept
> manual memory management intact. Most languages only offer one or the
> other. It's pretty unusual for a language as high-level as IDL to
> have manual memory management at all.
But IDL has to continue to support manual memory management or else
break backward compatibility. I would imagine that PTR_FREE and
OBJ_DESTROY will be around for a long time.
Mike
--
www.michaelgalloy.com
Research Mathematician
Tech-X Corporation
|
|
|
|
| Re: Do we need PTR_FREE anymore? [message #71992 is a reply to message #71928] |
Fri, 30 July 2010 10:07 |
James[2]
Messages: 44
Registered: November 2009
|
Member |
|
|
Wlandsman, that example doesn't sound particularly obscure to me -- it
seems like it could come up frequently when dealing with linked data
structures.
It's a little unusual that IDL has added garbage collection but kept
manual memory management intact. Most languages only offer one or the
other. It's pretty unusual for a language as high-level as IDL to
have manual memory management at all.
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
