To deal with such Fortran issues in several packages I deal with, I
wrote the SUtools package (https://github.com/bnaras/SUtools) that you
can try. The current version generates the registration assuming
implicit Fortran naming conventions though. (I've been meaning to
upgrade it to use the gfortran -fc-prototypes-external flag which should
be easy; I might just finish that during these holidays.)
There's a vignette as well:
https://bnaras.github.io/SUtools/articles/SUtools.html
-Naras
On 12/19/20 9:53 AM, Ivan Krylov wrote:
On Sat, 19 Dec 2020 17:04:59 +0000
"Koenker, Roger W" <rkoen...@illinois.edu> wrote:
There are comments in various places, including R-extensions §5.4
suggesting that .Fortran is (nearly) deprecated and hinting that use
of .Call is more efficient and now preferred for packages.
My understanding of §5.4 and 5.5 is that explicit routine registration
is what's important for efficiency, and your package already does that
(i.e. calls R_registerRoutines()). The only two things left to add
would be types (REALSXP/INTSXP/...) and styles (R_ARG_IN,
R_ARG_OUT/...) of the arguments of each subroutine.
Switching to .Call makes sense if you want to change the interface of
your native subroutines to accept arbitrary heavily structured SEXPs
(and switching to .External could be useful if you wanted to play with
evaluation of the arguments).
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
