[Rd] Use of C++ in Packages
jmount @end|ng |rom w|n-vector@com
Wed Apr 24 12:28:22 CEST 2019
I appreciate the writing on this.
However I definitely think there is a huge difference between "use with care" and "don't use". They just are not the same statement.
> On Mar 29, 2019, at 10:15 AM, Simon Urbanek <simon.urbanek using R-project.org> wrote:
> I think the main point of Tomas' post was to alert R users to the fact that there are very serious issues that you have to understand when interfacing R from C++. Using C++ code from R is fine, in many cases you only want to access R data, use some library or compute in C++ and return results. Such use-cases are completely fine in C++ as they don't need to trigger the issues mentioned and it should be made clear that it was not what Tomas' blog was about.
> I agree with Tomas that it is safer to give an advice to not use C++ to call R API since C++ may give a false impression that you don't need to know what you're doing. Note that it is possible to avoid longjmps by using R_ExecWithCleanup() which can catch any longjmps from the called function. So if you know what you're doing you can make things work. I think the issue here is not necessarily lack of tools, it is lack of knowledge - which is why I think Tomas' post is so important.
>> On Mar 29, 2019, at 11:19 AM, Jim Hester <james.f.hester using gmail.com> wrote:
>> 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.
>> : https://developer.r-project.org/Blog/public/2019/03/28/use-of-c---in-packages/
>> : https://github.com/JuliaLang/julia/issues/28606
>> : https://doi.org/10.1201/9781315381305
>> : http://www.lua.org/manual/5.1/manual.html#lua_pcall
>> : http://www.lua.org/manual/5.1/manual.html#lua_cpcall
>> R-devel using r-project.org mailing list
> R-devel using r-project.org mailing list
Our book: Practical Data Science with R http://www.manning.com/zumel/ <http://www.manning.com/zumel/>
[[alternative HTML version deleted]]
More information about the R-devel