| Re: copying of objects [message #32419] |
Wed, 09 October 2002 19:28  |
Paul Sorenson
Messages: 48
Registered: May 2002
|
Member |
|
|
"Sebastian Loebbert" <sebaaihb@peach.zrz.TU-Berlin.DE> wrote in message
news:Pine.LNX.4.44.0210081123550.3395-100000@peach.zrz.TU-Be rlin.DE...
> Hi all,
>
> how can I copy an object?
[...]
> different model trees, which is what I need.
[...]
> Any ideas?
Yes. Use the ALIAS keyword when adding to your models. You don't need to do
the save-and-restore trick!
-Paul Sorenson
-----------== Posted via Newsfeed.Com - Uncensored Usenet News ==----------
http://www.newsfeed.com The #1 Newsgroup Service in the World!
-----= Over 100,000 Newsgroups - Unlimited Fast Downloads - 19 Servers =-----
|
|
|
|
| Re: copying of objects [message #32422 is a reply to message #32419] |
Wed, 09 October 2002 14:25  |
JD Smith
Messages: 850
Registered: December 1999
|
Senior Member |
|
|
On Tue, 08 Oct 2002 05:40:52 -0700, David Fanning wrote:
> Sebastian Loebbert (sebaaihb@peach.zrz.TU-Berlin.DE) writes:
>
>> how can I copy an object?
>> E.g.:
>> v0 = OBJ_NEW('IDLgrVolume')
>> v1 = v0
>>
>> v1 only contains only a reference to v1, so I cannot use v0 and v1 in
>> different model trees, which is what I need. I was looking for
>> something like
>> v1 = OBJ_NEW( v0 ), but this doesn't work.
>
> Copying objects is one of those things that come up over and over again
> in object programming. In practice it seems difficult, because you have
> the problem of "deep" copying (I.e., pointers to pointers, other objects
> with pointers, etc.) You start thinking about recursion, then--of
> course--you get totally confused.
>
> You have a page full of diagrams with arrows going every which way, your
> migraine headache starts up again, and you begin to think, "Oh, hell,
> I'll just go back to thinking about where to invest my money in the
> stock market." It seems so much easier.
>
> Even if you call up RSI and ask the experts there, they give you the
> same old song and dance, and you work on it some more until your eyes
> cross and your backhand has disappeared from disuse.
>
> But it still never works right...until you discover the secret. :-)
>
> Here it is (already published in this newsgroup space, I guess, although
> I must have missed it...
Hi David,
Since one of your own pages
(http://www.dfanning.com/tips/saved_objects.html) documents one
potential peril encountered when using this very technique, I'm quite
surprised you weren't aware of it! Come to think of it, I don't spend
to much time reading my own web pages either;).
Here's the first reference I can find to it, about 4 years ago (ok, it
was me).
http://groups.google.com/groups?selm=36152C3D.3C8A3C73%40ast rosun.tn.cornell.edu
In any case, some advice for using this save/restore idea for copying,
saving, and reverting objects:
- For quick copying in a single IDL session, there's no need to worry
about the method-restoration stuff. If, however, you are restoring
a saved copy of an object into a new IDL session, you must deal with
the fact that the method definitions might be missed, and the class
structure might be incorrect (read the copious posts and David's
page on the issue).
- Remember that whatever variable you used to save the object is
overwritten upon restore. You can also get the objects with
judicious use of the RESTORED_OBJECTS keyword.
- Often, you don't want to copy certain data for which the operation
isn't relevant, e.g. temporary widget ID's, etc. You can "detach"
these before copying, and "reattach" them to the original by using
null pointers (or objects). See my many posts on this method.
- The "self" variable can be overwritten! Hard to believe, but true.
This is simultaneously dangerous and useful. Use it to easily
restore a saved version of an object right on top of itself
(e.g. "Revert to saved version..."), within one of the object's
methods. Do not forget to free the discarded version. Search on
"transmogrification" (a nomenclature for which I received not a
small amount of flack) for more on this possibility.
JD
|
|
|
|
|
|
|
|
| Re: copying of objects [message #32452 is a reply to message #32450] |
Tue, 08 October 2002 07:39 |
Struan Gray
Messages: 178
Registered: December 1995
|
Senior Member |
|
|
David Fanning, david@dfanning.com writes:
>
> Sebastian Loebbert (sebaaihb@peach.zrz.TU-Berlin.DE) writes:
>
>> thanks a lot, so it was not only me not finding the right
>> function but RSI not providing one.
>> That save-and-restore works fine, but I suppose I better
>> shouldn't use it too often, it doesn't look that performant...
>
> I don't know about "performant". When its the only
> alternative, I'd say it looks pretty darn good.
I've been playing around with saving objects recently and have
discovered some gotchas.
Performance is one. A 10 Mb dataset of mostly integer type that
takes under a second to read in from the raw binary file takes over
thirty second to save and about the same again to read in. Much faster
to write a copy method.
Also, if you seperate the saving and restoring into different
procedures you can run into some problems with namespace contamination.
I konw JD Smith and C. Markwardt have addressed this in their routines.
One extra tidbit that hit me hard until I figured out what was going
on was that if you save multiple objects in the same file and restore
later, the order that they appear in the RESTORED_OBJECTS array has
nothing to do with their hierarchy but is the order in which they were
oringinally created. If you use containers a lot, this can throw you out
of sync badly, particularly if the container is created after the
containees. Then, you have to do some digging to find out which of the
restored objects contains the others.
I don't want to say any more because this knowledge is the only way
I can compensate for my appalling hand-eye coordination and lack of
tennis ability at the up-coming meeting of the European Section of the
Advanced Programmers' Guild.
Struan
|
|
|
|
| Re: copying of objects [message #32455 is a reply to message #32452] |
Tue, 08 October 2002 05:40 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
Sebastian Loebbert (sebaaihb@peach.zrz.TU-Berlin.DE) writes:
> how can I copy an object?
> E.g.:
> v0 = OBJ_NEW('IDLgrVolume')
> v1 = v0
>
> v1 only contains only a reference to v1, so I cannot use v0 and v1 in
> different model trees, which is what I need.
> I was looking for something like
> v1 = OBJ_NEW( v0 ), but this doesn't work.
Copying objects is one of those things that come up
over and over again in object programming. In practice
it seems difficult, because you have the problem of
"deep" copying (I.e., pointers to pointers, other objects
with pointers, etc.) You start thinking about recursion,
then--of course--you get totally confused.
You have a page full of diagrams with arrows
going every which way, your migraine headache starts up
again, and you begin to think, "Oh, hell, I'll just go
back to thinking about where to invest my money in the
stock market." It seems so much easier.
Even if you call up RSI and ask the experts there,
they give you the same old song and dance, and you
work on it some more until your eyes cross and your
backhand has disappeared from disuse.
But it still never works right...until you discover
the secret. :-)
Here it is (already published in this newsgroup space,
I guess, although I must have missed it, and never with
as much unnecessary build-up as I'm going to give it).
RSI has already done the work for you!!
Seriously. The secret is SAVE and RESTORE. Here is the
secret to copying an object:
newobject = oldobject
Save, newobject, Filename='secret.sav'
Restore, 'secret.sav'
Done. Do you believe it? I know I didn't. But it works
like a charm.
Here is a function, then, to copy objects:
;******************************
;* A function to copy objects *
;******************************
FUNCTION OBJ_COPY, obj, TEMPDIRECTORY=temp
CATCH, error
IF (error NE 0) THEN $
BEGIN
CATCH, /CANCEL
RETURN, OBJ_NEW ()
ENDIF
IF (NOT OBJ_VALID (obj)) THEN MESSAGE, 'Invalid object reference.'
CD, CURRENT=origDir
IF (N_ELEMENTS (temp) NE 0) THEN CD, temp
newobj = obj
SAVE, newobj, FILENAME='temp.sav'
RESTORE, 'temp.sav'
FILE_DELETE, 'temp.sav'
IF (N_ELEMENTS (temp) GT 0) THEN CD, origDir
RETURN, newobj
END
Cheers,
David
--
David W. Fanning, Ph.D.
Fanning Software Consulting, Inc.
Phone: 970-221-0438, E-mail: david@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|
|
| Re: copying of objects [message #32518 is a reply to message #32422] |
Wed, 09 October 2002 19:40 |
David Fanning
Messages: 11724
Registered: August 2001
|
Senior Member |
|
|
JD Smith (jdsmith@as.arizona.edu) writes:
> Since one of your own pages
> (http://www.dfanning.com/tips/saved_objects.html) documents one
> potential peril encountered when using this very technique, I'm quite
> surprised you weren't aware of it! Come to think of it, I don't spend
> to much time reading my own web pages either;).
>
> Here's the first reference I can find to it, about 4 years ago
Four years ago!? Goodness, I'm happy if I can remember what
I had for dinner last night. :-(
I looked up that article. I wrote it in 1999 (when I was
first getting serious about writing an object book). I think
I ought to go through all my pages and eliminate anything
before 2001 as old hat. (Well, except DEVICE, DECOMPOSED=0,
which is timeless.)
Cheers,
David
P.S. Let's just say some people think I write these pages
for them. I don't. I write them for me. But I never dreamed
I'd actually have to read them after I wrote them. :-(
--
David W. Fanning, Ph.D.
Fanning Software Consulting, Inc.
Phone: 970-221-0438, E-mail: david@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
