Is it possible to assumeSafeAppend malloced memory?
monarch_dodra via Digitalmars-d-learn
digitalmars-d-learn at puremagic.com
Mon May 19 14:01:51 PDT 2014
On Monday, 19 May 2014 at 18:51:31 UTC, Dicebot wrote:
> If it still resorts to GC in this case, utility of such
> addition sounds questionable.
It's not really an "addition" as much as it is a "necessary
building block to make higher order GC functions work": For
example, "dup" was recently made a druntime library implemented
function, and as such, required that function to allocate, before
building data onto it.
> Huh, will it also make possible to call `realloc` if capacity
> is exceeded?
AFAIK, using the "GC.realloc" (or "GC.extent") function on it
directly would not work. This may or may not be an issue with how
"GC.realloc" is designed. The reason for this is because this
functions are actually "extremelly" low level, and simply request
GC memory, without knowing or caring about the APPENDABLE data.
So while the calls could succeed, the result would not be useable.
Currently, you could just use "reserve" or simply allocate again,
to achieve almost the desired result. reserve+assumeSafeAppend
would basically be a "void-extend" (as opposed to "size", which
would be an "initialized extend").
At the end of the day though, it can all be done, but it's really
about what you want to expose in "object.d".
More information about the Digitalmars-d-learn
mailing list