[Rd] Use of C++ in Packages

[Hugh Marera]

Some of us are learning about development in R and use R in our work data
analysis pipelines. What is the best way to identify packages that
currently have these C++ problems? I would like to be able to help fix the
bugs but more importantly not use these packages in critical work
pipelines. Any C++ R package bug squashing events out there?

Regards

Hugh

On Mon, Apr 1, 2019 at 6:23 PM Tomas Kalibera <tomas.kalibera using gmail.com>
wrote:

> On 3/30/19 8:59 AM, Romain Francois wrote:
> > tl;dr: we need better C++ tools and documentation.
> >
> > We collectively know more now with the rise of tools like rchk and
> improved documentation such as Tomas’s post. That’s a start, but it appears
> that there still is a lot of knowledge that would deserve to be promoted to
> actual documentation of best practices.
> Well there is quite a bit of knowledge in Writing R Extensions and many
> problems could have been prevented had it been read more thoroughly by
> package developers. The problem that C++ runs some functions
> automatically (like destructors), should not be too hard to identify
> based on what WRE says about the need for protection against garbage
> collection.
>
>  From my experience, one can learn most about R internals from debugging
> and reading source code - when debugging PROTECT errors and other memory
> errors/memory corruption, common problems caused by bugs in native C/C++
> code - one needs to read and understand source code involved at all
> layers, one needs to understand the documentation covering code at
> different layers, and one has to think about these things, forming
> hypotheses, narrowing down to smaller examples, etc.
>
> My suggestion for package authors who write native code and want to
> learn more, and who want to be responsible (these kinds of bugs affect
> other packaged indirectly and can be woken up by inconsequential and
> correct code changes, even in R runtime): test and debug your code hard
> - look at UBSAN/ASAN/valgrind/rchk checks from CRAN and run these tools
> yourself if needed. Run with strict barrier checking and with gctorture.
> Write more tests to increase the coverage. Specifically now if you use
> C++ code, try to read all of your related code and check you do not have
> the problems I mentioned in my blog. Think of other related problems and
> if you find about them, tell others. Make sure you only use the API from
> Writing R Extensions (and R help system). If you really can't find
> anything wrong about your package, but still want to learn more, try to
> debug some bugs reported against R runtime or against your favorite
> packages you use (or their CRAN check reports from various tools). In
> addition to learning more about R internals, by spending much more time
> on debugging you may also get a different perspective on some of the
> things about C++ I pointed to. Finally, it would help us with the
> problem we have now - that many R packages in C++ have serious bugs.
>
> Tomas
>
> ______________________________________________
> R-devel using r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

	[[alternative HTML version deleted]]