comp.lang.idl-pvwave archive: archive » Important object lesson

Home » Public Forums » archive » Important object lesson

Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend

Re: Important object lesson [message #12157 is a reply to message #12110]

Tue, 30 June 1998 00:00

Mark Hadfield
Messages: 783
Registered: May 1995

Senior Member

David Fanning wrote in message ...
> Phillip David (pdavid@earthling.net) writes:
>
>> I've been doing some more playing around with objects, and learned that
there
>> is a HUGE difference between creating an object with a null constructor
and
>> destructor and creating an object with no constructor or destructor.
>> ...
> ...
>
> Actually, I think this is a function of how many directories you have
> on your path. If the INIT and CLEANUP methods are not compiled when
> IDL has to use them, it looks for a file named myclass__init.pro or
> myclass__cleanup.pro in the directories specified by the !PATH
> system variable. If you have a lot of files there, it can take
> a long time!

I'm sure this is the correct explanation.

Interestingly enough, this does not seem to apply to subclasses. If one
creates a class
MyClass that inherits from SomeOtherClass, then IDL attempts to resolve
calls to
obj_new('MyClass') by first searching for MyClass::Init & if it can't find
that it settles for SomeOtherClass:Init. But as far as I can tell it does
this once only, either at the time MyClass is first defined or (more likely)
the first time it creates a MyClass. After that the rule "when initialising
MyClass call SomeOtherClass::Init" seems to be lodged in its memory banks,
with the result that if you later compile a MyClass::Init it will be
ignored.

This explains some confusing experiences I have had with IDL objects.

The reason for this is clear in the light of Phillip's experience. Some IDL
objects, eg graphics objects, pick up lots of behaviour from their parents,
and if IDL had to resolve every method all the way up the inheritance tree
every time it was called, searching the !path at every step, performance
would be affected severely.

It also suggests a solution (though not a very elegant one): make all your
objects subclasses of something, if only a dummy class, and make sure one of
the superclasses has explicit Init and Cleanup methods.

--
Mark Hadfield, m.hadfield@niwa.cri.nz http://www.niwa.cri.nz/~hadfield/
National Institute for Water and Atmospheric Research
PO Box 14-901, Wellington, New Zealand

Report message to a moderator

[Message index]

		Important object lesson By: Phillip & Suzanne on Tue, 23 June 1998 00:00
		Re: Important object lesson By: mirko_vukovic on Thu, 02 July 1998 00:00
		Re: Important object lesson By: Mark Hadfield on Tue, 30 June 1998 00:00
		Re: Important object lesson By: Mark Hadfield on Tue, 30 June 1998 00:00
		Re: Important object lesson By: Mark Hadfield on Tue, 30 June 1998 00:00
		Re: Important object lesson By: Mark Hadfield on Tue, 30 June 1998 00:00
		Re: Important object lesson By: davidf on Mon, 29 June 1998 00:00
		Re: Important object lesson By: Phillip & Suzanne on Mon, 29 June 1998 00:00

Previous Topic:	Transparent surfaces?
Next Topic:	Re: Determining machine endian-ness

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

] [

]

Current Time: Thu Oct 09 23:23:18 PDT 2025

Total time taken to generate the page: 1.68079 seconds