| Re: structures, arrays of pointers and assignment [message #53745] |
Wed, 02 May 2007 09:24  |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Ingo von Borstel writes:
> Not so easy. As mentioned above, all the routines are written such that
> they accept variable types as used for dealing with a single set of
> data. Wouldn't want to change their basic structure.
Unless I am missing something here, isn't this just a
case of parameter overloading. Something like this,
added to your routines would surely suffice:
IF Size(param, /TNAME) EQ 'STRUCT' THEN BEGIN
field = param.field
aStruct = Temporary(param)
param = Temporary(field)
ENDIF
And then at the end of the routine, before you exit:
IF N_Elements(aStruct) NE 0 THEN BEGIN
aStruct.field = param
param = Temporary(aStruct)
ENDIF
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Sepore ma de ni thui. ("Perhaps thou speakest truth.")
|
|
|
|
| Re: structures, arrays of pointers and assignment [message #53746 is a reply to message #53745] |
Wed, 02 May 2007 09:08  |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Ingo von Borstel writes:
> But now I wonder why deleting an entry works:
>
> PRO delete_entry, trackvalues, number
> IF NOT PTR_VALID(trackvalues.value[number]) THEN BEGIN
> MESSAGE, "Trackvalues number is not a valid record. Nothing done",
> /CONTINUE
> RETURN
> ENDIF
> PTR_FREE, trackvalues.value[number]
> trackvalues.used[number] = 0
> trackvalues.description[number] = ''
> END
>
> IDL>delete_entry, sep213.trackvalues, 3
> will result in the deletion of the 3rd (or 4th, depends upon where you
> start counting) entry... Why the hell does this work then? Shouldn't
> work, if this was also passed by value...
Ah, because pointers are variables and are passed by reference:
http://www.dfanning.com/misc_tips/pointers.html
Isn't it exciting to learn about IDL? :-)
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Sepore ma de ni thui. ("Perhaps thou speakest truth.")
|
|
|
|
| Re: structures, arrays of pointers and assignment [message #53747 is a reply to message #53746] |
Wed, 02 May 2007 08:50 |
Ingo von Borstel
Messages: 54
Registered: September 2006
|
Member |
|
|
Hi,
>> Any clue as to why? My guess it's to do with passing elements of a
>> struct prohibits its modification by a subroutine.
>
> I think you already know the answer. When you pass a de-referenced
> structure variable, you pass it by value, and when you pass
> the structure itself, you pass it by reference. When something
> is passed by value, a copy of the thing is made and worked on.
I feared this to be the case. Thanks for sort-of confirming my guess.
>> If so, is there a way to circumvent this behaviour?
The point is the following:
I have written a bunch of routines which work well on a single set of
data; their result are a number of different structs. Now I want to
compare them, plot one vs. the other, filter them propperly etc. That's
fine as long as I do it with one set of data at a time. But I want to do
that not only for one set of data, but I want to compare also different
data sets with eachother.
Then the amount of variables starts to get long... so creating a struct
that contains all essential data for a single set was my idea to keep
order. Any other idea how to keep together those things that belong
together (e.g.makes the use of SAVE much easier, if I want to preserve
some results for future reference).
> If you mean circumvent this behavior within the confines
> of pass by value or pass by reference, the answer is no.
> But this is software. Anything is possible! You could,
> for example, have your program return a value that you then
> assigned to the proper field in the structure. But the
Hm... Let's see. Let's create a wrapper function of the same name, and
with the same arguments:
var.struct = do_something(var.struct,...)
That will work. Probably it'll work in most other cases as I mostly only
modify one variable.
But now I wonder why deleting an entry works:
PRO delete_entry, trackvalues, number
IF NOT PTR_VALID(trackvalues.value[number]) THEN BEGIN
MESSAGE, "Trackvalues number is not a valid record. Nothing done",
/CONTINUE
RETURN
ENDIF
PTR_FREE, trackvalues.value[number]
trackvalues.used[number] = 0
trackvalues.description[number] = ''
END
IDL>delete_entry, sep213.trackvalues, 3
will result in the deletion of the 3rd (or 4th, depends upon where you
start counting) entry... Why the hell does this work then? Shouldn't
work, if this was also passed by value...
> easiest thing to do, of course, since you have the
> structure hanging around or you wouldn't be able to pass
> a *field* of the structure, is to just pass the whole darn
> thing. That seems simple enough to me.
Not so easy. As mentioned above, all the routines are written such that
they accept variable types as used for dealing with a single set of
data. Wouldn't want to change their basic structure.
Best regards,
Ingo
--
Ingo von Borstel <newsgroups@planetmaker.de>
Public Key: http://www.planetmaker.de/ingo.asc
If you need an urgent reply, replace newsgroups by vgap.
|
|
|
|
| Re: structures, arrays of pointers and assignment [message #53750 is a reply to message #53747] |
Wed, 02 May 2007 06:47 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Ingo von Borstel writes:
> Any clue as to why? My guess it's to do with passing elements of a
> struct prohibits its modification by a subroutine.
I think you already know the answer. When you pass a de-referenced
structure variable, you pass it by value, and when you pass
the structure itself, you pass it by reference. When something
is passed by value, a copy of the thing is made and worked on.
There is no possibility of affecting the original.
> If so, is there a way to circumvent this behaviour?
If you mean circumvent this behavior within the confines
of pass by value or pass by reference, the answer is no.
But this is software. Anything is possible! You could,
for example, have your program return a value that you then
assigned to the proper field in the structure. But the
easiest thing to do, of course, since you have the
structure hanging around or you wouldn't be able to pass
a *field* of the structure, is to just pass the whole darn
thing. That seems simple enough to me.
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting, Inc.
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Sepore ma de ni thui. ("Perhaps thou speakest truth.")
|
|
|
|
|
|
| Re: structures, arrays of pointers and assignment [message #53807 is a reply to message #53745] |
Wed, 02 May 2007 23:54 |
Ingo von Borstel
Messages: 54
Registered: September 2006
|
Member |
|
|
Hi,
>> Not so easy. As mentioned above, all the routines are written such that
>> they accept variable types as used for dealing with a single set of
>> data. Wouldn't want to change their basic structure.
>
> Unless I am missing something here, isn't this just a
> case of parameter overloading. Something like this,
> added to your routines would surely suffice:
>
> IF Size(param, /TNAME) EQ 'STRUCT' THEN BEGIN
> field = param.field
> aStruct = Temporary(param)
> param = Temporary(field)
> ENDIF
>
> And then at the end of the routine, before you exit:
>
> IF N_Elements(aStruct) NE 0 THEN BEGIN
> aStruct.field = param
> param = Temporary(aStruct)
> ENDIF
Hmm... this sounds like a way to possibly go. Now I only have to make
sure to find a way how to distinguish the two different kind of structs
(both astruct and astruct.field being a struct, though a different one).
But that's feasable. Thanks for the suggestion.
Cheers,
Ingo
--
Ingo von Borstel <newsgroups@planetmaker.de>
Public Key: http://www.planetmaker.de/ingo.asc
If you need an urgent reply, replace newsgroups by vgap.
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
