New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rcpp question #14

Enchufa2 opened this Issue Nov 16, 2015 · 2 comments


None yet
2 participants

Enchufa2 commented Nov 16, 2015

I don't know if it is important, but it worries me this line (and equivalent ones). Do you know the implications of putting here a true/false? Because, from the documentation, it is not clear to me.


This comment has been minimized.


Bart6114 commented Nov 16, 2015

Strawled a bit through the Rcpp code and found this:

     * creates a new external pointer wrapping the dumb pointer p. 
     * @param p dumb pointer to some object
     * @param set_delete_finalizer if set to true, a finalizer will 
     *        be registered for the external pointer. The finalizer
     *        is called when the xp is garbage collected. The finalizer 
     *        is merely a call to the delete operator or the pointer
     *        so you need to make sure the pointer can be "delete" d
     *        this way (has to be a C++ object)
    explicit XPtr(T* p, bool set_delete_finalizer = true, SEXP tag = R_NilValue, SEXP prot = R_NilValue)

So, I think we can simply drop the false (and thus default to true) as a destructor for the Simulator class is defined anyway. I think initially I set it to false as I was assuming that the destructor would be called anyway when the instances lifetime was up (i.e. when the Rcpp process ended).

Have you tested the new codebase for mem leaks?

@Enchufa2 Enchufa2 closed this Nov 16, 2015

@Enchufa2 Enchufa2 reopened this Nov 16, 2015


This comment has been minimized.


Enchufa2 commented Nov 16, 2015

Ok, understood. So we can drop the false from the Simulator creation, but it is necessary in the activities (seize, release...), because we lose the pointer and they would be garbage-collected then.

I tested the code with valgrind and there are no leaks.

@Enchufa2 Enchufa2 closed this Nov 16, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment