[Rd] Memory allocation in C/C++ vs R?

Prof Brian Ripley ripley at stats.ox.ac.uk
Fri Apr 30 09:56:21 CEST 2010


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



More information about the R-devel mailing list