[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Temporary variables still checked out
- Subject: Re: Temporary variables still checked out
- From: Peter Mason <menakkis(at)my-deja.com>
- Date: Wed, 26 May 1999 23:56:29 GMT
- Newsgroups: comp.lang.idl-pvwave
- Organization: Deja.com - Share what you know. Learn what you don't.
- References: <firstname.lastname@example.org>
- Xref: news.doit.wisc.edu comp.lang.idl-pvwave:14926
<...> Every time I run it, if I hit the okay button,
> I get the message from IDL 'Temporary variables still checked out', or
> at least it's virtually like that, after the program exits.
> I don't know what's going on, but is it something to do with the
> structures and passing by value etc.
Phil, you're essentially doing your assignment to a temporary variable
when you do something like (structure.member)=val instead of
structure.member=val. The brackets tell IDL to evaluate their
contents, and this incurs the creation of a temporary variable. The
assignment is lost when the temp variable is destroyed, and you get that
inscrutable "programmer's revenge" error message in lieu of a warning
that something hasn't worked out quite as you might have expected.
> ((*(info.ptr)).optIndex)[i,*] = 0
=> Instead of this, try (*info.ptr).optIndex[i,*]=0; etc.
Things DO get a bit unsettling when (structures of) pointers to
structures are involved, but a bit of command line action will
normally clarify IDL's workings with brackets soon enough. (Basically,
you must restrict your bracketing to just the pointer component(s).)
There was quite a bit of discussion about all this
some time back (at least a year) on the NG. As I recall, Stein Vidar
pretty much sussed out how it all works - it may be worth your while
searching a news archive for this thread.
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---