Skip to content

[Rcpp-devel] Persistent memory allocation in C++

3 messages · Dirk Eddelbuettel, schattenpflanze at arcor.de

Original
schattenpflanze at arcor.de
# 
Hello,

I am facing the task of writing an R interface to a rather large C++ 
library. The library does not make use of the R API. Rcpp seems to be a 
good idea, but I have the following, general questions concerning R and 
C++ integration:

1. In the C++ library, new objects are allocated on the heap in great 
numbers (using shared pointers and the new operator and using STL 
containers). The "Writing R Extensions" manual offers information about 
memory allocation in section 6.1. However, only the case of C-style 
allocations is discussed. Can I safely use "new" and do my own memory 
management? (Note that I do not use the R API, and I catch all C++ 
exceptions with the macros offered by Rcpp.)

2. In addition, I need to keep a small number of objects in memory in 
between the calls to the interface. (The construction of these objects 
is quite expensive.) More precisely, I would like to have static shared 
pointers in my C++ file which are initialized during the first call to 
one of my functions and persist until further calls (or until I detach 
my library). I have tried this already. The static shared pointer is 
initialized correctly. The object is not destructed until I manually 
reset the shared pointer, and thus free the memory, during the second 
call. I am, however, not sure whether this is _really safe_ to do (and 
whether or not it is operating system dependent).

I would very much appreciate your advice!

Best regards,
Peter
Dirk Eddelbuettel
# 
Hi Peter,
On 7 March 2011 at 09:58, schattenpflanze at arcor.de wrote:
| I am facing the task of writing an R interface to a rather large C++ 
| library. The library does not make use of the R API. Rcpp seems to be a 
| good idea, but I have the following, general questions concerning R and 
| C++ integration:
| 
| 1. In the C++ library, new objects are allocated on the heap in great 
| numbers (using shared pointers and the new operator and using STL 
| containers). The "Writing R Extensions" manual offers information about 
| memory allocation in section 6.1. However, only the case of C-style 

Note that that discussion has 

   If there is an error during allocation it is handled by R, so if these
   routines return the memory has been successfully allocated or freed.

If you do not need this feature, you can of course use new/delete at
will. And if you look closely at Rcpp sources, we do too.  What 6.1 is about
is that you should not mix R and C++ memory allocation.

| allocations is discussed. Can I safely use "new" and do my own memory 
| management? (Note that I do not use the R API, and I catch all C++ 
| exceptions with the macros offered by Rcpp.)

Yes, you should be fine. C++ memory management for C++ objects, you claim it,
you manage it, you free. Other libraries do that too.
 
| 2. In addition, I need to keep a small number of objects in memory in 
| between the calls to the interface. (The construction of these objects 
| is quite expensive.) More precisely, I would like to have static shared 
| pointers in my C++ file which are initialized during the first call to 
| one of my functions and persist until further calls (or until I detach 
| my library). I have tried this already. The static shared pointer is 
| initialized correctly. The object is not destructed until I manually 
| reset the shared pointer, and thus free the memory, during the second 
| call. I am, however, not sure whether this is _really safe_ to do (and 
| whether or not it is operating system dependent).

That is a common practice. You can even also pass these to R via external
pointers using the Rcpp::XPtr class.

Hope this helps, Dirk

| I would very much appreciate your advice!
| 
| Best regards,
| Peter
| _______________________________________________
| Rcpp-devel mailing list
| Rcpp-devel at lists.r-forge.r-project.org
| https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
schattenpflanze at arcor.de
# 
Thank you very much for your help!
Yes, that was actually all I needed to know. I can now confidently start 
to experiment with Rcpp :-).

Best regards,
Peter