From simon.urbanek at r-project.org  Fri Sep  4 23:21:49 2009
From: simon.urbanek at r-project.org (Simon Urbanek)
Date: Fri, 4 Sep 2009 17:21:49 -0400
Subject: [Rd] asking for suggestions: interface for a C++ class
In-Reply-To: <91FB958D-CFB2-45CD-8EF1-2206E04C4EE6@erasmusmc.nl>
References: <91FB958D-CFB2-45CD-8EF1-2206E04C4EE6@erasmusmc.nl>
Message-ID: <58DF18A9-8F3F-4EDD-A073-6F994252A25B@r-project.org>

Yurii,

On Sep 4, 2009, at 16:54 , Yurii Aulchenko wrote:

> Dear All,
>
> I would like to have an advice for designing an R library, and  
> thought that R-devel may be the best place to ask given so many  
> people who are highly expert in R are around.
>
> We are at an early stage of designing an R library, which is  
> effectively an interface to a C++ library providing fast access to  
> large matrices stored on HDD as binary files.

[FWIW there are already several packages that do waht you describe -  
see e.g. ff, bigMemory, nws, ...]


> The core of the C++ library is relatively sophisticated class, which  
> we try to "mirror" using an S4 class in R. Basically when a new  
> object of that class is initiated, the C++ constructor is called and  
> essential elements of the new object are reflected as slots of the R  
> object.
>
> Now as you can imagine the problem is that if the R object is  
> removed using say "rm" command, and not our specifically designed  
> one, the C++ object still hangs around in RAM until R session is  
> terminated.

You must have some link between the S4 object and your C++ object -  
ideally an external pointer - so all you have to do is to attach a  
finalizer to it via R_RegisterCFinalizer or R_RegisterCFinalizerEx. In  
that finalizer you simply free the C++ object and all is well.

Note that R uses a garbage collector so the object won't go away  
immediately after it went out of scope - only after R thinks it needs  
to reclaim memory. You can use gc() to force garbage collection to  
test it.


> This is not nice, and also may be a problem, as the C++ object may  
> allocate large part of RAM. We can of cause replace generic "rm" and  
> "delete" functions, but this is definitely not a nice solution.
>

... and it doesn't tackle the issue - objects can go out of scope by  
other means than just rm(), e.g.:
f <- function() { ...; myGreatObject }
f()
# the great object is gone now since it was not assigned anywhere


> Sounds like rather common problem people may face, but unfortunately  
> I was not able to find a solution.
>

Cheers,
Simon



[Rd] asking for suggestions: interface for a C++ class
Simon Urbanek