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.urba...@r-project.org> > wrote: > > Jim, > > 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. > > Cheers, > Simon > > >> On Mar 29, 2019, at 11:19 AM, Jim Hester <james.f.hes...@gmail.com> wrote: >> >> First, thank you to Tomas for writing his recent post[0] 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 >> community. >> >> These same issues will also occur with any newer language (such as >> Rust or Julia[1]) 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 [2]) >> >>> 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[3] and lua_cpcall[4] 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 >> finalizers. >> >> 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. >> >> [0]: >> https://developer.r-project.org/Blog/public/2019/03/28/use-of-c---in-packages/ >> [1]: https://github.com/JuliaLang/julia/issues/28606 >> [2]: https://doi.org/10.1201/9781315381305 >> [3]: http://www.lua.org/manual/5.1/manual.html#lua_pcall >> [4]: http://www.lua.org/manual/5.1/manual.html#lua_cpcall >> >> ______________________________________________ >> R-devel@r-project.org mailing list >> https://stat.ethz.ch/mailman/listinfo/r-devel >> > > ______________________________________________ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel --------------- John Mount http://www.win-vector.com/ <http://www.win-vector.com/> Our book: Practical Data Science with R http://www.manning.com/zumel/ <http://www.manning.com/zumel/> [[alternative HTML version deleted]] ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
