comp.lang.idl-pvwave archive
Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado

Home » Public Forums » archive » Structure field concatenation
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Return to the default flat view Create a new topic Submit Reply
Re: Structure field concatenation [message #21649 is a reply to message #21614] Wed, 06 September 2000 13:34 Go to previous messageGo to previous message
John-David T. Smith is currently offline  John-David T. Smith
Messages: 384
Registered: January 2000
Senior Member
David Fanning wrote:
>
> Martin Schultz (martin.schultz@dkrz.de) writes:
>
>> The only reason to do this that I could accept without further
>> quirking is if you tell me there is a lot of penalty if you manually
>> deallocate and reallocate the memory instead of letting IDL do it.
>> Haven't tested, but I would doubt that it makes a big difference.
>
> I really don't think there is any difference at all.
> If it makes you feel safer, by all means free pointers
> yourself. I just wanted to make the point once again that
> IDL really does have some nice features. This aspect
> of pointer memory management is one of them. :-)

I just wanted to point out that this technically isn't pointer memory management
at all. Rather, it's simply the same old variable memory management we know and
love:

IDL> a=[1,2,3]
IDL> a=1

...no memory loss there! The only difference is that *heap* variables are being
handled in the pointer case. So Martin, if you're happy with this, you should
be happy with David's method. Of course you might always use "delvar,a", but
somehow I doubt it.

I'm being pedantic only to prevent readers (especially the Java-enabled among
them) getting confused about what kind of memory management IDL really
provides. The best way to stay clear on the issue is to think about pointers as
what they are: references to IDL variables which are exactly the same as any
other variable except for being hidden ("on the heap") and persistent ("not
cleaned up by function/procedure exits"). They do *not* point directly to
memory (just as variables like "a" above don't directly map to memory --
thankfully for us).

JD


--
J.D. Smith /*\ WORK: (607) 255-6263
Cornell University Dept. of Astronomy \*/ (607) 255-5842
304 Space Sciences Bldg. /*\ FAX: (607) 255-5875
Ithaca, NY 14853 \*/
[Message index]
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: Re: IDLgrROI and normalized coords
Next Topic: Re: taking the widget plunge. help

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Wed Oct 08 19:26:55 PDT 2025

Total time taken to generate the page: 0.00455 seconds