From wavexx at users.sf.net  Mon Jul  6 00:13:54 2009
From: wavexx at users.sf.net (Yuri D'Elia)
Date: Mon, 06 Jul 2009 00:13:54 +0200
Subject: [Rd] Memory management issues
References: <20090705165445.68dae639@abz8111lx.eurac.edu>
	<8ec76080907051259q4744d40bp46b2434b086d5adc@mail.gmail.com>
Message-ID: <wavexx-F25043.00135406072009@ger.gmane.org>

In article 
<8ec76080907051259q4744d40bp46b2434b086d5adc at mail.gmail.com>,
 Whit Armstrong <armstrong.whit at gmail.com> wrote:

> If you are in control of the c++ library (i.e. it is not from a
> vendor), then you can also override the new operator of your object so
> that it allocates an SEXP.  if you implement PROTECT/UNPROTECT calls
> correctly, then GC will not be a problem.

The library returns addresses which may not be from the top of the 
allocated object. For some pre-calculated values, I actually use a 
shared memory pool.

I really need to be able to 'wire' this address directly into the SEXP.

Like I wrote in another message, changing the GC code (if necessary) 
could be a viable option.

> Sources here:
> R backend storage policy: 
> http://github.com/armstrtw/r.tslib.backend/tree/master
> tslib: http://github.com/armstrtw/tslib/tree/master

I really like this approach, it would turn useful for many other 
projects :).

Thanks



[Rd] Memory management issues
Yuri D'Elia