[Rd] Good practice for packages with Fortran and C code

[Ivan Krylov]

В Fri, 25 Oct 2024 15:03:54 -0500
fh using fharrell.com пишет:

> Now I find that I can get rid of init.c, and  change NAMESPACE to use
> useDynLib(package name, list of compiled routine names) (without
> .registration and .fixes) after making sure the Fortran and C
> routines are not named the same as the package name.  The routines
> are called using .Fortran(binary module name, args) or .Call(C binary
> module name, ...).
> 
> Can anyone see any problem with streamlining in this way?

"Writing R Extensions" 1.5.4 says:

>> this approach is nowadays deprecated in favour of supplying
>> registration information

...which is the init.c approach you have been using.

With useDynLib(package name, list of compiled routine names), R has to
ask the operating system's dynamic loader to find exported functions in
the DLL by their names. With function registration, it is enough for
the DLL to export one function (package_name_init) and then directly
provide function pointers together with their desired names to R. The
latter is considered more reliable than talking to the operating
system's dynamic loader. It also provides an opportunity for R to check
the number of arguments and their types.

> I'm also using Fortran's dynamic array allocation instead of passing
> working vectors from R.

This is quite reasonable, with the following two things to care about:

1. If the stat= argument is absent from the allocate statement and the
allocation is unsuccessful, program execution stops. Stopping the whole
R process may lose unsaved data belonging to the user, so it's best to
always provide the stat= argument and handle allocation failures
somehow.

2. Calls to R API from within the Fortran program may signal R errors
and jump away from the function call without deallocating the memory
that R knows nothing about. From Fortran code, it's most simple not to
call R API while having allocated memory, although it's not impossible
to use Fortran 2003 C interoperability to call R's error handling
interfaces (described in Writing R Extensions 6.12).

-- 
Best regards,
Ivan