В Fri, 25 Oct 2024 15:03:54 -0500 f...@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 ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
