13452
What the *bleep* is IDL doing: COMPILE_OPT
If you are a modern IDL programmer, the line compile_opt
idl2 is at the top of every function/procedure/method/$MAIN program you
write. If it's not, I'm here to convince you it should be.
First off, what exactly is a compile_opt. A compile_opt
is a statement which is processed by the IDL compiler to change the behavior of
the compiler. It is processed in order of the statements (meaning if you put a
compile_opt in the middle of your code, it's effect
would only apply to code after the compile_opt).
What does compile_opt
idl2
do? The idl2 flag sets two flags for the IDL compiler, DEFINT32 and STRICTARR.
DEFINT32 sets the default size of IDL
integers to be 32-bits rather than 16-bits. This is useful because it aligns
the default behavior of IDL with the standard size of a C language long, so you can rely on the more liberal -2147483648
and 2147483647 underflow/overflow values of type long.
STRICTARR prevents IDL from using
parenthesis for array indexing.
Why is this important? Consider the following:
offset = input(0)
data = input[100] *
offset
What is input? One of the difficulties of untyped languages
is the ability to discern the intent of code from a small context. In this
case, input could either be: a function and an array, or an array
which is being accessed two different ways (valid syntax without compile_opt
idl2). By always putting compile_opt
idl2 at the beginning of every function, this ambiguity is removed.
You might be thinking to yourself, "But I like indexing
array's with parenthesis, I'll just stick compile_opt
idl2 in any new code I write". In the words of a once great robot,
"DANGER! DANGER, WILL ROBINSON!" Consider the following:
test22.pro
PRO test22
resolve_routine, 'a', /either,/compile_full_file
print, 'Answer = ', b('stuff')
END
----
a.pro
FUNCTION b, istuff
COMPILE_OPT idl2, hidden
RETURN, 'b'
END
FUNCTION a, istuff
COMPILE_OPT idl2
RETURN, 'a'
END
If you try to run test22, the
function b will not be resolved. This is because the symbols for test22.pro
are generated before the resolve_routine and since there
is no reference to b it will be treated as a
variable. After the resolve_routine, the compiler
will not override the variable type of b for the
function. This problem will also present itself if you sick compile_opt
idl2 in the middle of your code. When IDL gets confused, you lose.
Here are some simple tricks to follow to avoid these
pitfalls:
- Always
put compile_opt idl2 at the top of your
function/procedure.
- If
your function doesn't have compile_opt
idl2, add it! Worse case, you have to refactor array parenthesis to
brackets. But this simple refactor will reduce headaches down the road by
making your code more readable and extensible.
- If
you are working in legacy code (and insist it remain legacy code), be aware if
external code is using compile_opt
idl2. If it is, double check your function/procedure/variable names to
prevent IDL from getting confused.