Re: update variable in structure [message #66950 is a reply to message #66949] |
Tue, 16 June 2009 09:19   |
Michael Galloy
Messages: 1114 Registered: April 2006
|
Senior Member |
|
|
M. Suklitsch wrote:
> Hi everybody!
>
>
> Today I have a question regarding the update of variables within a
> structure, which does not work as I would expect.
>
> Say we have a very simple program:
>
> ===============
> PRO update_value, input
>
> input = input MOD 5
>
> END
> ===============
>
> [In reality, this subroutine/program does some more sophisticated
> things, but this is sufficient to prove my point. ;-) ]
>
> Okay, now we call this routine with a variable holding an integer
> value.
> IDL> my_value = 8
> IDL> update_value, my_value
> IDL> help, my_value
> MY_VALUE INT = 3
>
> So far, so good. Now we do exactly the same, but this time the
> variable is embedded in a structure:
> IDL> my_struct = {my_value:8}
> IDL> update_value, my_value
> IDL> help, my_struct, /STRUC
> ** Structure <8220044>, 1 tags, length=2, data length=2, refs=1:
> MY_VALUE INT 8
>
> And now the rather simple question: how come this doesn't work?
> Normally IDL is eager to overwrite variables of any kind. On some
> occasions, I've seen it overwriting the "parental" variable of a
> duplicated one. And more important: is there a way to get the above
> thing working?
Well, I assume you mean to refer to the field in the structure you just
created, as in:
IDL> update_value, my_struct.my_value
IDL> help, my_struct.my_value
<Expression> INT = 8
The reason my_struct.my_value was not modified is that only "named
variables" are passed by reference, so changes to them by the called
routine will still be in effect at the caller level. The expression
"my_struct.my_value" is not a named variable (named variables are just
the name of a variable like "my_value" was in your previous examples),
so modification to it inside update_value are only to a local variable.
> Maybe important, maybe not: I'm working with IDL 7.0 and have tried it
> on Solaris and Linux.
Should not matter for this.
Mike
--
www.michaelgalloy.com
Associate Research Scientist
Tech-X Corporation
|
|
|