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

2023-09-23 Thread Ralf Stubner
Hi Dirk, > 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 usi

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

2023-09-23 Thread Ralf Stubner
On Sat, Sep 23, 2023 at 9:49 AM Simon Urbanek wrote: > > The copy constructor doesn't actually create a copy, it only acts as a > wrapper that preserves the same EXTPTR object, it is akin to increasing the > reference count, so the C++ class wrapped in the EXTPTR is only released when > the EXT

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

2023-09-23 Thread Dirk Eddelbuettel
PS There is another neat use case where a shared_ptr is allocated. Now we cannot wrap a shared_ptr in an XPtr but ... we can stick the shared_ptr into a struct, and allocate that with new and then make_xptr. You are then back to well-understood C++ semantics. Dirk -- dirk.eddelbuettel.com |

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

2023-09-23 Thread 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 ob

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

2023-09-23 Thread Simon Urbanek
The copy constructor doesn't actually create a copy, it only acts as a wrapper that preserves the same EXTPTR object, it is akin to increasing the reference count, so the C++ class wrapped in the EXTPTR is only released when the EXTPTR can be garbage-collected, i.e. all references are gone (incl

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

2023-09-23 Thread Ralf Stubner
Hi everybody, 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