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