[Rcpp-devel] Life-cycle of Rcpp::XPtr

[Dirk Eddelbuettel]

Hi Ralf,

On 23 September 2023 at 08:28, Ralf Stubner wrote:
| I have a question concerning the file-cycle of Rcpp::XPtr: Consider a
| XPtr with the default delete finalizer wrapping some pointer. If I use
| the copy constructor to create another XPtr, this is pointing at the
| same underlying object as expected. What happens if one of these
| pointers goes out of scope and is at some point garbage collected? Is
| the underlying object deleted leaving the other XPtr with a broken
| pointer? Or is the object protected by the existence of the other
| pointer? From my experiments I have the impression that the latter is
| the case, which would be the desired behaviour. But it would be nice
| if one could be sure.

I had done some experiments with 'expanded finalizers' that use more logging
(which I find quite convenient via `spdl` -- same nice spdlog interface now
from R and C++) so you could add some display of the pointer address, check
on nullness etc.

I have done a bit more work using XPtr in the context of the tiledb (and the
related, possibly upcoming tiledbsoma package not yet on CRAN) where I use an
enum (which requires C++17 in the use I have there) to 'type tag' each
external pointer and on each use check I have the correct type. I am not
thinking to a simple unordered_map from enum to string to also make more
informed errors (showing the type as string rather than enum int value) as
well as maybe an enhanced show or print at the R level. I have long been
meaning to farm that out into a new (simple) add-on package (see issue #1212)
and should get on with that.  (The 'still somewhat raw' XPtr extension in
tiledb is eg here:
https://github.com/TileDB-Inc/TileDB-R/blob/1e7bd2fa4e54f3e152c4fec3a65343df49d3f525/src/libtiledb.h#L80-L160
and the check_xptr_tag is then used throughout the files in src/.

Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org