Hi Ralf,
On Sat, 23 Sept 2023 at 14:56, Dirk Eddelbuettel <e...@debian.org> wrote:
>
>
> 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.
The answer is yes, XPtr works as a shared_ptr, so you can be sure that
the object will be protected until the last reference to it is
deleted. A quick check:
#include <Rcpp.h>
using namespace Rcpp;
class Test {
public:
Test() { Rcout << this << " created" << std::endl; }
~Test() { Rcout << this << " deleted" << std::endl; }
};
// [[Rcpp::export]]
SEXP test_new() {
return XPtr<Test>(new Test());
}
// [[Rcpp::export]]
SEXP test_copy(SEXP x_) {
XPtr<Test> x(x_);
return x;
}
/*** R
x <- test_new()
#> 0x55a93e3845d0 created
y <- test_copy(x)
rm(x); invisible(gc())
rm(y); invisible(gc())
#> 0x55a93e3845d0 deleted
*/
Best,
Iñaki
--
Iñaki Úcar
Assistant Professor of Statistics
Director of the Master in Computational Social Science
Department of Statistics | Big Data Institute
Universidad Carlos III de Madrid
Av. de la Universidad 30, 28911 Leganés, Spain
Office: 7.3.J25, Tel: +34 916248804
_______________________________________________
Rcpp-devel mailing list
Rcpp-devel@lists.r-forge.r-project.org
https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
