On 15/11/2023 4:37 a.m., Michael Meyer via R-package-devel wrote:
Greetings, Suppose I wanted to develop a package with C++ code that contains virtual functions which the package user should define.It's assumed that evaluation is expensive so we do not want to define these in R and then call these R-functions from C++. Is this a reasonable idea with a standard solution?Are there packages that do this? Thanks in advance for all answers,
I think you would be better off having your package evaluate R functions. If that's too slow, the user could use Rcpp or hand programming to put most of the computation into C++ or C code.
It seems unlikely the overhead of passing the results from the user's C++ code through R would be significant if the computations themselves were slow. On the other hand, the user has the opportunity of prototyping in R, which may turn out to be fast enough.
To get the prototyping possibility with your approach, you'd need to write and maintain two interfaces: C++ to C++ and C++ to R.
One situation where this might be worth the trouble would be if you expect the user's function to be fast, but your code needs to call it a huge number of times, so the overhead adds up.
Duncan Murdoch ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
