Add argument to XPtr template to run finalizer on exit (fixes #655)

[jeroen]

See #655. This adds an additional parameter to XPtr which specifies if the finalizer should run on exit in the same spirit as the underlying R_RegisterCFinalizerEx.

I confirmed that this works. Default is still FALSE so the current behavior will be unchanged.

[codecov-io]

Codecov Report

Merging #656 into master will not change coverage.
The diff coverage is 0%.

@@           Coverage Diff           @@
##           master     #656   +/-   ##
=======================================
  Coverage   92.91%   92.91%           
=======================================
  Files          65       65           
  Lines        3303     3303           
=======================================
  Hits         3069     3069           
  Misses        234      234

Impacted Files	Coverage Δ
inst/include/Rcpp/XPtr.h	62.16% <0%> (ø)	✅

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 0566d7c...e3799de. Read the comment docs.

[eddelbuettel]

Looks reasonable to me.

[jeroen]

OK perfect, I'll add a NEWS item and bump the version.

[eddelbuettel]

Great, and a changelog entry, please.

Are the data structures in your client packages C or C++? I am just wondering if you could also get this for free for C++ destructor semantics on your side . Just checking ...

[jjallaire]

Spelling of parameter here (finalizeoOnExit should be finalizeOnExit)

[eddelbuettel]

May also move the entry to the bottom. They are mostly chronological. In any even I can clean up both when finalizing the release "real soon now".

[jjallaire]

@eddelbuettel I think the default finalizer will delete the C++ object thereby calling the destructor (so without this change there is actually no way to guarantee that the destructor is called prior to the process exiting)

@jeroen FWIW in some cases I've found it better to not let C++ destructors get called at process exit because the runtime context of an exiting process can be so stripped down (or non-deterministic across multiple C++ objects getting destroyed) that the destructor either crashes or hangs. i.e. sometimes it's better to just let the OS clean up than to try to explicitly do so within the process. Obviously this doesn't work in all cases, but I know that many things like mutexes, sockets, file handles, memory, etc. are freed automatically by the OS at process exit.

[eddelbuettel]

Leaving the default at false is definitely the way to go.

[jeroen]

OK fixed the typo and moved the \item{} to the bottom.

[eddelbuettel]

I launched a full reverse-depends check just in case, but we won't know til tomorrow how it does.

[eddelbuettel]

Rev deps were all fine, results in RcppCore/rcpp-logs@8103eff

[jeroen]

Rev deps were all fine, results in RcppCore/rcpp-logs@8103eff

Let's send it to CRAN then :D

[eddelbuettel]

Yes, which is why I ran the two previous reverse-depends. Probably by Friday.

Given the long tail of these reverse dependencies, Rcpp is a littler slower to make it from Incoming but you should be able to rely on it come next week.