Closed mdpiper closed 5 years ago
This is how babel maps SIDL types to Fortran data types. Would it make sense to just use these names? So, get_value_int
, get_value_bool
, etc.
SIDL type | Real Fortran 2003/2008 type |
---|---|
int | integer(c_int32_t) integer(kind=sidl_int) |
long | integer(c_int64_t) |
float | real(c_float) |
double | real(c_double) |
bool | integer(c_int) |
char | integer(c_signed_char) |
string | type(c_ptr) |
fcomplex | complex(c_float_complex) |
dcomplex | complex(c_double_complex) |
Or we could use the LAPACK naming scheme. So get_value_s
(or get_svalue
?), etc.
lapack code | Fortran name |
---|---|
S | REAL |
D | DOUBLE PRECISION |
C | COMPLEX |
Z | COMPLEX*16 or DOUBLE COMPLEX |
I like the SIDL types.
Thank you also for the link to the Babel docs. I'll see what else is there that I can use.
Are integers always signed 32-bit integers?
Also deferred we might want shorts, and unsigned versions (and bytes (C's unsigned chars)).
Closed with #17.
In Fortran, the type and rank of an argument must be known at compile time. This implies that we need BMI getters and setters for each intrinsic type that a model may use (i.e.,
get_value_int
,get_value_float
,get_value_double
, etc.). However, we can simplify calls to the getters and setters by defining generic procedure interfaces with implementations for all the types that we expect to be passed at runtime. The user would only have to callget_value
, and not be concerned with type. The model developer writing a BMI would still have to writeget_value_int
,get_value_float
, etc.For this issue, I'll implement the following methods:
get_value_int
get_value_float
get_value_double
get_value_ref_int
get_value_ref_float
get_value_ref_double
get_value_at_indices_int
get_value_at_indices_float
get_value_at_indices_double
set_value_int
set_value_float
set_value_double
set_value_at_indices_int
set_value_at_indices_float
set_value_at_indices_double
I'll leave long and complex types for a separate, deferred, issue.
cc @sc0tts, @mcflugen