The R docs say that there are two methods that the C programmer can allocate memory, one where R automatically frees the memory on return from .C/.Call, and the other where the user takes responsibility for freeing the storage. Both methods involve using R-provided functions. What happens when the user uses the standard "new" allocator? What about when a C++ application uses STL and that library allocates memory? In both of these cases the R-provided functions are not used (to my knowledge), yet I have not seen any problems. How is the memory that R manages and garbage collects kept separate from the memory that is allocated on the C++ side quite independently of what R is doing? Thanks, Dominick [[alternative HTML version deleted]]
On Fri, 30 Apr 2010, Dominick Samperi wrote:> The R docs say that there are two methods that the C programmer can > allocate memory, one where R automatically frees the memory on > return from .C/.Call, and the other where the user takes responsibility > for freeing the storage. Both methods involve using R-provided > functions. > > What happens when the user uses the standard "new" allocator?Standard in C++, not C, that is.> What about when a C++ application uses STL and that library > allocates memory? In both of these cases the R-provided functions > are not used (to my knowledge), yet I have not seen any problems.Then you have been fortunate, maybe because you work on a very limited range of compilers and OSes? I have been plagued by this on modern Windows toolchains where it seems that dynamically linked C++ code only works if called from a C++ main program (and R is a C main program).> How is the memory that R manages and garbage collects kept > separate from the memory that is allocated on the C++ side > quite independently of what R is doing?R does not use C++. So the 'C++ side' is entirely in the packages which choose to use it, and they manage their own memory usage via the C++ runtime they are linked to. Basically R mallocs all the memory it uses, and the hope is that the C++ runtime does not interfere with malloc (and of course it is in practice also obtaining memory by malloc or its equivalent).> Thanks, > Dominick > > [[alternative HTML version deleted]][Please do note that what the posting guide asked you NOT to do.] -- Brian D. Ripley, ripley at stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UK Fax: +44 1865 272595
Brian's answer was pretty exhaustive - just one more note that is indirectly related to memory management: C++ exception handling does interfere with R's error handling (and vice versa) so in general STL is very dangerous and best avoided in R. In addition, remember that regular local object rules are broken because you are not guaranteed to leave a function the regular way so there is a high danger of leaks and inconsistencies when using C++ memory management unless you specifically account for that. That said, I have written C++ code that works in R but you have to be very, very careful and think twice about using any complex C++ libraries since they are unlikely written in R-safe way. Cheers, Simon On Apr 30, 2010, at 1:03 AM, Dominick Samperi wrote:> The R docs say that there are two methods that the C programmer can > allocate memory, one where R automatically frees the memory on > return from .C/.Call, and the other where the user takes responsibility > for freeing the storage. Both methods involve using R-provided > functions. > > What happens when the user uses the standard "new" allocator? > What about when a C++ application uses STL and that library > allocates memory? In both of these cases the R-provided functions > are not used (to my knowledge), yet I have not seen any problems. > > How is the memory that R manages and garbage collects kept > separate from the memory that is allocated on the C++ side > quite independently of what R is doing? > > Thanks, > Dominick > > [[alternative HTML version deleted]] > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > >