[Rcpp-devel] "binding" Rcpp::InternalFunction or Rcpp::CppFunction

[Christian Authmann]

On 01.08.2014 13:45, Dirk Eddelbuettel wrote:
> But beyond those drawbacks you can use C++11 (and even C++14 if your
> compiler supports it) in your Rcpp packages on CRAN now.  See
> RcppBDT and RcppCNPy for the mechanics.

Great. Just creating a CppFunction that wraps std::function simplified 
the code a lot, but still leaves the original problem of not having a 
proper function pointer, thus being unable to implement 
CppFunction::get_function_ptr().

My original question was whether a CppFunction where get_function_ptr() 
returns a nullptr is valid or not, when used in the context of an 
InternalFunction. My examples work just fine and pass valgrind tests, 
but that doesn't mean that what I'm doing isn't terribly broken.

> | e) some other approach you'll advise me of ;)
>
> We have examples of doing something similar (at least if I understand
> your issue correctly) via R's external pointers and the Rcpp::XPtr
> class which wraps them.

If I understand your suggestion correctly, I should provide the 
DataProvider to the environment as an XPtr, and have the R script pass 
it back as an argument, similar to this:

Foo getdata(DataProvider *p, int id) {
   return p->getData(id);
}

DataProvider provider(/* arguments specifying data source*/);
RInside R;
R["dataprovider"] = Rcpp::Xptr(&provider);
R["getdata"] = Rcpp::InternalFunction( &getdata );

and have the R script do:
data <- getdata(dataprovider, 42)


That might work (if I removed the finalizer and added some typecasting), 
but I don't like the API it exposes to the R script. (My use case is 
more complex than the example, and this style of API gets verbose fast)

I'd prefer the original approach of exposing bind'ed functions, and 
would appreciate any help in figuring out how to do it safely.


-- 
Christian Authmann
Philipps-Universität Marburg
Fachbereich Mathematik und Informatik
AG Datenbanksysteme
Hans-Meerwein-Straße
D-35032 Marburg