[Rd] Use of C++ in Packages
j@me@@|@he@ter @end|ng |rom gm@||@com
Fri Mar 29 16:19:19 CET 2019
First, thank you to Tomas for writing his recent post on the R
developer blog. It raised important issues in interfacing R's C API
and C++ code.
However I do _not_ think the conclusion reached in the post is helpful
> don’t use C++ to interface with R
There are now more than 1,600 packages on CRAN using C++, the time is
long past when that type of warning is going to be useful to the R
These same issues will also occur with any newer language (such as
Rust or Julia) which uses RAII to manage resources and tries to
interface with R. It doesn't seem a productive way forward for R to
say it can't interface with these languages without first doing
expensive copies into an intermediate heap.
The advice to avoid C++ is also antithetical to John Chambers vision
of first S and R as a interface language (from Extending R )
> The *interface* principle has always been central to R and to S
before. An interface to subroutines was _the_ way to extend the first
version of S. Subroutine interfaces have continued to be central to R.
The book also has extensive sections on both C++ (via Rcpp) and Julia,
so clearly John thinks these are legitimate ways to extend R.
So if 'don't use C++' is not realistic and the current R API does not
allow safe use of C++ exceptions what are the alternatives?
One thing we could do is look how this is handled in other languages
written in C which also use longjmp for errors.
Lua is one example, they provide an alternative interface;
lua_pcall and lua_cpcall which wrap a normal lua call and return
an error code rather long jumping. These interfaces can then be safely
wrapped by RAII - exception based languages.
This alternative error code interface is not just useful for C++, but
also for resource cleanup in C, it is currently non-trivial to handle
cleanup in all the possible cases a longjmp can occur (interrupts,
warnings, custom conditions, timeouts any allocation etc.) even with R
It is past time for R to consider a non-jumpy C interface, so it can
continue to be used as an effective interface to programming routines
in the years to come.
More information about the R-devel