| Re: saving variables between calls to a procedure? [message #31586 is a reply to message #31585] |
Thu, 01 August 2002 11:38   |
![Paul Van Delst[1] is currently offline](theme/default/images/xoffline.png.pagespeed.ic.XRkd1fkXye.png "Paul Van Delst[1] is currently offline")
Paul Van Delst[1]
Messages: 1157
Registered: April 2002
|
Senior Member |
|
|
JD Smith wrote:
>
> On Thu, 01 Aug 2002 07:45:52 -0700, Paul van Delst wrote:
>
>>
>> I'm not worried about extending arrays like a=[a,b], but pointers ala
>> *ptr=[*ptr,10]. If ptr is pointing to some data structure (scalar or
>> array), it seems feasible to me that the next position in memory could
>> be occupied by something else. If one then does a *ptr=[*ptr,10], what
>> happens to what was in that memory? Is it "protected" somehow so that
>> the value "10" is then placed in the next "free" spot in memory giving a
>> non-contiguous array [not efficient, but safe], or are the contents
>> clobbered and replaced by the value "10" [very very bad], or are the
>> contents moved to some other memory location so that the original
>> position can be used to store the value "10" [relatively efficient(?)
>> and safe].
>
> The best way to think of pointers in IDL is to forget what you know from
> other languages like C, and regard them as special unnamed, but otherwise
> perfectly normal IDL variables which live in a global heap available
> everywhere, and thus aren't created/destroyed when you enter or exit
> routines.
Ahh. Fair enough.
> Here we see we can recall the pointer heap variable off the heap. And
> just as for normal IDL variables, you can arbitrarily reassign them,
> extend them, change the data type of, etc.:
I did not know you could do that with pointers in IDL.
> Of course, this ease of type/size/layout changing hides lots of
> behind-the-scenes memory-juggling, some of which may be rather
> inefficient, so it pays to have a little more familiarity with the methods
> these operations use internally.
Yeah.... apart from inspecting data files, I use IDL mostly to prototype code for Fortran
90/95 so I tend to avoid (or, as in this case, not even know about <ehem>) the neato
power-user type of tricks.
paulv
--
Paul van Delst
CIMSS @ NOAA/NCEP/EMC Beer is good.
Ph: (301)763-8000 x7274 My wife.
Fax:(301)763-8545
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
