.C(.NAME, ..., NAOK = FALSE, DUP = TRUE, PACKAGE, ENCODING) .Fortran(.NAME, ..., NAOK = FALSE, DUP = TRUE, PACKAGE, ENCODING)... list of arguments passed in
(including any names given to the arguments), but reflecting any
changes made by the C or Fortran code.
| R | C |
| Fortran | integer |
| int * | integer |
| numeric | double * |
| double precision | -- or -- |
| float * | real |
| complex | Rcomplex * |
| double complex | logical |
| int * | integer |
| character | char ** |
| [see below] | raw |
| unsigned char * | not allowed |
| list | SEXP * |
| not allowed | other |
| SEXP | not allowed |
integer and
logical are int, not long as in S. This
difference matters on most 64-bit platforms, where int is
32-bit and long is 64-bit (but not on 64-bit Windows). Note: The Fortran type corresponding to logical is
integer, not logical: the difference matters on some
Fortran compilers. Numeric vectors in R will be passed as type double * to C
(and as double precision to Fortran) unless the argument has
attribute Csingle set to TRUE (use
as.single or single). This mechanism is
only intended to be used to facilitate the interfacing of existing C
and Fortran code. The C type Rcomplex is defined in ‘Complex.h’ as a
typedef struct {double r; double i;}. It may or may not be
equivalent to the C99 double complex type, depending on the
compiler used. Logical values are sent as 0 (FALSE), 1
(TRUE) or INT_MIN = -2147483648 (NA, but only if
NAOK = TRUE), and the compiled code should return one of these
three values: however non-zero values other than INT_MIN are
mapped to TRUE. Missing (NA) string values are passed to .C as the string
"NA". As the C char type can represent all possible bit patterns
there appears to be no way to distinguish missing strings from the
string "NA". If this distinction is important use .Call. .Fortran passes the first (only) character string of a
character vector as a C character array to Fortran: that may be usable
as character*255 if its true length is passed separately. Only
up to 255 characters of the string are passed back. (How well this
works, and even if it works at all, depends on the C and Fortran
compilers and the platform.) Lists, functions are other R objects can (for historical reasons) be
passed to .C, but the .Call interface is much
preferred. All inputs apart from atomic vectors should be regarded as
read-only, and all apart from vectors (including lists), functions and
environments are now deprecated..Fortran. Symbol names containing underscores are not valid Fortran 77 (although
they are valid in Fortran 9x). Many Fortran 77 compilers will allow
them but may translate them in a different way to names not containing
underscores. Such names will often work with .Fortran (since
how they are translated is detected when R is built and the
information used by .Fortran), but portable code should not use
Fortran names containing underscores. Use .Fortran with care for compiled Fortran 9x code: it may not
work if the Fortran 9x compiler used differs from the Fortran 77
compiler used when configuring R, especially if the subroutine name
is not lower-case or includes an underscore. It is possible to use
.C and do any necessary symbol-name translation yourself.options(CBoundsCheck = TRUE). In that case raw,
logical, integer, double and complex vector arguments are copied both
before and after calling the compiled code. The first copy made is
extended at each end by guard bytes, and on return it is checked that
these are unaltered. For .C, each element of a character
vector uses guard bytes..Call and
.External which are more flexible and have better
performance. These functions are primitive, and .NAME is always
matched to the first argument supplied (which should not be named).
The other named arguments follow ... and so cannot be
abbreviated. For clarity, should avoid using names in the arguments
passed to ... that match or partially match .NAME.
dyn.load, .Call.The ‘Writing R Extensions’ manual.