comp.lang.idl-pvwave archive
Messages from Usenet group comp.lang.idl-pvwave, compiled by Paulo Penteado

Home » Public Forums » archive » Re: linking programs/ procedures
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Return to the default flat view Create a new topic Submit Reply
Re: linking programs/ procedures [message #19780 is a reply to message #19779] Wed, 26 April 2000 00:00 Go to previous messageGo to previous message
John-David T. Smith is currently offline  John-David T. Smith
Messages: 384
Registered: January 2000
Senior Member
David Fanning wrote:
>
> Troy Carter (tcarter@princeton.edu) writes:
>
>> You can also use:
>>
>> @/path/to/program.pro
>>
>> At the beginning of your code. This will compile program.pro before
>> running the rest of your code.
>
> Uh, no, not exactly. It will put the program.pro code *into*
> the program file as if you had actually typed it there. It
> doesn't compile anything, and it is completely unnecessary. :-(

Oh David, always making these sweeping statements to entice my refutation...

I suppose you meant that it's unnecessary in the case of running a routine from
"program" elsewhere. For this you are correct. But it does have its uses. My
favorite is with common blocks (whose use should, of course, be limited). As
everyone knows, once a common block is defined, you can simple reference it
with:

common my_common

i.e. without any of the variables listed out. This saves typing, but more
importantly, leaves only one location which needs to be modified when common
block variables are added or removed. But there's a catch... you have to
compile the defining routine *first*... i.e. the point of entry into a suite of
programs which share the common block must be a single file/routine. If you try
to enter elsewhere, it will generate a compiler error, and refuse to run.. you
can't simply "call" a defining routine at the beginning of each routine in the
suite either, since it's a compile time, not a run-time error. So, you resort
to making *all* of the routines a defining routine for the common block, but
including all the variables in each common block statement. But this
unfortunately means modification requires you to change each and every one (over
30 places for one of my common blocks) so you're back where you started. But
enter @ to save the day. In a file, call it my_common.pro, put:

common my_common, var1, var2, var3, thefinalvar

or whatever. Then, in each routine which needs it, simply put:

@my_common

in place of "common my_common", and you get the best of both worlds.... single
point of modification, yet every routine capable of defining the common block.
If you need to perform a standard version lookup or some such in all your
routines, you could also include it in my_common.

Just trying to defend poor little "@" from the onslaught.

JD

--
J.D. Smith |*| WORK: (607) 255-5842
Cornell University Dept. of Astronomy |*| (607) 255-6263
304 Space Sciences Bldg. |*| FAX: (607) 255-5875
Ithaca, NY 14853 |*|
[Message index]
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: tvrd and device,decomposed=0
Next Topic: Re: Object Rubberband Selection Box

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Sat Oct 11 14:59:07 PDT 2025

Total time taken to generate the page: 0.96017 seconds