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