Thanks Luke ! I had seen the usage and discussion of growable vectors, as
well as using SET_TRUELENGTH with SETLENGTH and didn't necessarily want to get
even more out of API compliance :-). but if that looks like it will allowed
(subject to perhaps changes) that seems like the better way forw
On Wed, 15 Jan 2025 15:30:36 +
"Merlise Clyde, Ph.D." wrote:
> For memory limited machines, the alloc/copy was a problem for memory
> usage - and if I recall was one of the reasons in 2008 I switched to
> SETLENGTH, which doesn't seem to do an allocation ??? If there is
> going to be an abso
On Wed, 15 Jan 2025, Iris Simmons wrote:
I don't think memcpy works well for VECSXP. The elements being overwritten
need to have their reference counts decreased and the new elements need to
have theirs increased.
You do not want to use memcpy or inanyother way try to write to the
locations in
I don't think memcpy works well for VECSXP. The elements being overwritten
need to have their reference counts decreased and the new elements need to
have theirs increased.
Also, I don't entirely know how accurate everything I'm about to say is,
but I think you need to be using SET_TRUELENGTH and
Thanks for the added explanation Iris and Tomas!
So looking at the code for xlengthgets, it does appear that I may take a memory
hit for multiple large objects due to the second allocation before the old
objects are possibly garbage collected. There are about 12 such instances
per function
On 1/15/25 05:26, Merlise Clyde, Ph.D. wrote:
I am trying to determine the best way to eliminate the use of SETLENGTH to
truncate over allocated vectors in my package BAS to eliminate the NOTES about
non-API calls in anticipation of R 4.5.0.
From WRE: "At times it can be useful to allocate
