From tom@@@k@||ber@ @end|ng |rom gm@||@com  Mon Apr  1 18:23:31 2019
From: tom@@@k@||ber@ @end|ng |rom gm@||@com (Tomas Kalibera)
Date: Mon, 1 Apr 2019 18:23:31 +0200
Subject: [Rd] Use of C++ in Packages
In-Reply-To: <5A14862F-729A-484C-A196-CA5F1D91B524@rstudio.com>
References: <CAD6tx97B3zHikY9Cs+DnMXdOFFUn76ONoTupZT8QTaqo7+xZCA@mail.gmail.com>
 <DA086757-A81C-4E25-AE4D-2E4BCA187941@R-project.org>
 <CAJXgQP2OuQ98zzj-8CNSFVBTv4OU0tsA12HH++x=r4vpxi7Osw@mail.gmail.com>
 <F68C848D-AE93-4CA9-9314-1ACDB23B87F6@r-project.org>
 <5A14862F-729A-484C-A196-CA5F1D91B524@rstudio.com>
Message-ID: <b6fa43a9-335b-5cf2-b91a-40daf38e8cae@gmail.com>

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



[Rd] Use of C++ in Packages
Tomas Kalibera