[Rd] Registration of native routines

[Avraham Adler]

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