On 08/07/2013 01:16 PM, monarch_dodra wrote:
> On Wednesday, 7 August 2013 at 18:56:40 UTC, Ali Çehreli wrote:
>> But question to others: I wouldn't want garbage filled memory, right?
>> So I should consider GC.calloc first.
> Depends on why you think garbage is a problem I guess.
>
> If it is because of false pointers
Precisely.
>, yet you aren't storing any pointers, then simply allocate
> using GC.BlkAttr.NO_SCAN. Then, garbage won't be a problem.
But the attribute is in effect throughout the lifetime of that memory
block, right?
> Otherwise, yeah, calloc should do the trick. Unfortunatly, calloc
> doesn't return much other than a void*, so depending on what you are
> doing, a qalloc + memset might be better.
qalloc seems better but just like in C and C++, when comparing GC.malloc
and GC.calloc, the default choice should always be GC.calloc.
So, GC.malloc is preferable only if the data that I am going to place in
there will never need GC scanning. Because it provides zeroed-out
memory, GC.calloc seems to be slower but I hear that that is not a
problem on modern systems. (I have vague recollections that the system
has already zeroed-out memory; but I am not sure.)
> Also, keep in mind that 0-initialization is not T.init initialization.
> This means that calloc'ed memory is not "initialized" per say, it is
> just zero'ed memory. An emplace is necessary before attempting, say an
> assignment.
Exactly. I wouldn't expect more from a function that returns void*. :)
Ali
