data type changes and fits header definitions I
rclark wrote on Nov 26, 2008
The calculations in some code need to have some fairly widespread changes
in data type-- specifically eliminating the explicit use of the complex
data type, and real needs to be replaced with double.
So starting at the beginning...
In SPP code a line like:
varT = clgetT("varNAME")
gets varNAME which is defined in a par file as:
varNAME,T,...
varNAME may actually come from a default value in a par file or from
the command line invoking the task. The task is initially called from
a cl script but everything else is SPP with a little fortran here and
there.
So my question...
How much consistency checking for type or automatic type conversion is
done? How critical is type consistency from parfile (or command line)
to clget to final SPP vairable?
in data type-- specifically eliminating the explicit use of the complex
data type, and real needs to be replaced with double.
So starting at the beginning...
In SPP code a line like:
varT = clgetT("varNAME")
gets varNAME which is defined in a par file as:
varNAME,T,...
varNAME may actually come from a default value in a par file or from
the command line invoking the task. The task is initially called from
a cl script but everything else is SPP with a little fortran here and
there.
So my question...
How much consistency checking for type or automatic type conversion is
done? How critical is type consistency from parfile (or command line)
to clget to final SPP vairable?
Mike Fitzpatrick wrote on Nov 26, 2008
It depends on the type of conversion being done, e.g. a clgetb() will complain if you enter anything but 'yes' or 'no', but a clgeti() will simply truncate a floating point value. Internally in SPP people have use YES/NO instead of TRUE/FALSE and for some compilers this is fine, but recent GCC will complain about a type mismatch. There is a coerce() function to morph pointers (mainly by changing alignment), otherwise things are done using the normal type casting functions like 'int()'.
Short answer, you'll know if you broke something, and don't try to push the limits.
-Mike
Short answer, you'll know if you broke something, and don't try to push the limits.
-Mike
Last post on Nov 26, 2008