| Re: include file? [message #20496 is a reply to message #20494] |
Thu, 29 June 2000 00:00   |
John-David T. Smith
Messages: 384
Registered: January 2000
|
Senior Member |
|
|
As you can see from the various postings, there are a variety of ways to include
data "globally" to be shared among many routines, all of which I use in some
form. Each has it's strengths and weaknesses. In case people are confused by
which they should select, I thought I'd outline the various
advantages/disadvantages of each:
1. Variables in an include File (@filename)
* Advantages: Easy access to variables. Values can be initialized
within the file itself, and need no explicit initialization. Any arbitrary code
can execute, not just variable setting. This can be especially convenient when
used in concert with common blocks (see below).
* Disadvantages: Changes in the values cannot be shared among routines or
multiple calls to a single routine -- works best for read-only constants and/or
shared code segments. Updating the value requires recompiling each including
routine, or restarting the session.
2. System variables (!FOO).
* Advantages: Available everywhere for both reading and writing.
* Disadvantages: Difficulty setting -- IDL used to validate system variables at
compile time, which means you'd need to define them with "defsysv" *before* any
routine referencing them was compiled. At least with version 5.3, validity
checking is done at run time, eliminating this problem. Once a system variable
is defined, much like a named structure, it cannot be redefined with a different
data type or size in that session. Each system variable you define must be
initialized explicitly.
3. Restoring a .sav. This is really equivalent to #1 for variable definition
only, except the file to be included has actually been compiled.
*Advantages: Loads more quickly than file includes. Variables are
pre-initialized.
*Disadvantages: Unlike method #1, only variables are set ... you can't run
arbitrary code. In order to update the variable data, you must redefine them
and then recompile the .sav, which is typically more difficult than recompiling
a routine (though perhaps not more difficult than recompiling many routines).
This need not even be a .sav file... any file (such as flat ascii) can be read
and parsed and variables assigned, but .sav's are somewhat more convenient (if
not portable among different programs), and preserve variable names simply.
Since you can't just peek in a .sav to see what variables it defines, you risk
variable name collision in routines which restore it. Restoring object
variables introduces a whole rash of subtleties (see previous postings on the
subject).
4. Common blocks.
* Advantages: RSI designed common blocks exactly for the case of sharing global
data. Common block variables can be both read and written to, and assigned
values of different size/type (unlike system variables). Shorthand allows you
to avoid explicitly mentioning each variable in a common block usage statement
(but see below).
* Disadvantages: Common blocks must be initialized and cannot be redefined
within a given session. The shortcut usage statement requires that the
declaring "common" statement (with all the variables listed) be *compiled*
before any routine invoking it. This compile-ordering restriction is similar to
the case for system variables in older versions of IDL. The only solution is
making each common block statement a declaring statement. This then makes adding
or deleting common block variables difficult, if its use is spread throughout
many routines/files. Combining with method #1 achieves single-point updates
(still for only one session), and solves the compile order issue.
Hope this helps clear things up.
JD
--
J.D. Smith /*\ WORK: (607) 255-6263
Cornell University Dept. of Astronomy \*/ (607) 255-5842
304 Space Sciences Bldg. /*\ FAX: (607) 255-5875
Ithaca, NY 14853 \*/
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
