Registration of native routines
I believe Dr. Ripley said that the UseDynLib doesn't address the middle two points of the list. I experimented with the Delaporte package timing calls using both methods, and they were within 1~2 microseconds of each other using microbenchmark. Since the more complicated way is now expressly preferred, it isn't a big deal for me personally to change so the next version of Delaporte will use CallMethod/useDynLib(foo, .registration=TRUE) etc. I can see how in more complicated packages that could become more burdensome. Thanks, Avi
On Wed, Feb 22, 2017 at 9:34 AM, Jeroen Ooms <jeroen.ooms at stat.ucla.edu> wrote:
On Tue, Feb 14, 2017 at 5:25 PM, Prof Brian Ripley <ripley at stats.ox.ac.uk> wrote:
Registration has similar benefits to name spaces in R code: - it ensures that the routines used by .C, .Call etc are those in your package (without needing a PACKAGE argument). - it avoids polluting the search space for native routines with those from your package. - it checks the number of arguments passed to .Call/.External, and the number and optionally the type for .C/.Fortran. - it finds native routines faster, especially if 10s of name spaces are loaded.
Do these benefits also hold for packages that currently use useDynLib exclusively in combination symbol names? E.g for the example from WRE: useDynLib(foo, myRoutine, myOtherRoutine) Which is invoked via: .Call(myRoutine, x, y) What ambiguity or pollution is introduced by foo:::myRoutine? Should manually registering 'myRoutine' in C still be mandatory in this case? It was nice having the NAMESPACE as the central declaration of callable C routines. The "R_registerRoutines" system will require maintaining additional C code which re-declares all callable C functions from other compilation units. This introduces additional complexity for package authors and might become a source of bugs when we forget to update the registrations when C functions have changed.
______________________________________________ R-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel