[Rd] Problem with new("externalptr")
    Herve Pages 
    hpages at fhcrc.org
       
    Wed Jan 30 00:40:32 CET 2008
    
    
  
Hi,
It seems that new("externalptr") is always returning the same instance, and
not a new one as one would expect from a call to new(). Of course this is hard
to observe:
  > new("externalptr")
  <pointer: (nil)>
  > new("externalptr")
  <pointer: (nil)>
since not a lot of details are displayed.
For example, it's easy to see that 2 consecutive calls to new("environment")
create different instances:
  > new("environment")
  <environment: 0xc89d10>
  > new("environment")
  <environment: 0xc51248>
But for new("externalptr"), I had to use the following C routine:
  SEXP sexp_address(SEXP s)
  {
        SEXP ans;
        char buf[40];
        snprintf(buf, sizeof(buf), "%p", s);
        PROTECT(ans = NEW_CHARACTER(1));
        SET_STRING_ELT(ans, 0, mkChar(buf));
        UNPROTECT(1);
        return ans;
  }
Then I get:
  > .Call("sexp_address", new("externalptr"))
  [1] "0xde2ce0"
  > .Call("sexp_address", new("externalptr"))
  [1] "0xde2ce0"
Isn't that wrong?
I worked around this problem by writing the following C routine:
  SEXP xp_new()
  {
        return R_MakeExternalPtr(NULL, R_NilValue, R_NilValue);
  }
so I can create new "externalptr" instances from R with:
  .Call("xp_new")
I understand that there is not much you can do from R with an "externalptr"
instance and that you will have to manipulate them at the C level anyway.
But since new("externalptr") exists and seems to work, wouldn't that be
better if it was really creating a new instance at each call?
Thanks!
H.
    
    
More information about the R-devel
mailing list