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
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
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
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 |
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
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
