On 08/04/14 16:58, Artur Skawina wrote:
Just be careful; I used the name 'capacity' because it fit
into your example, but 'capacity' shouldn't be overloaded like
that - it works very differently from the magic built-in property.
Yes, I was thinking that I'd better use a different name. (Actual
On 04/07/14 22:58, Joseph Rushton Wakeling wrote:
> On 05/04/14 02:18, Artur Skawina wrote:
>> Not portably, as it will be libc and/or allocator specific.
>
> I think that's fine. I would be using it in circumstances where it's nice to
> have if I can get it, not a problem if I can't. As long a
On 05/04/14 02:18, Artur Skawina wrote:
Not portably, as it will be libc and/or allocator specific.
I think that's fine. I would be using it in circumstances where it's nice to
have if I can get it, not a problem if I can't. As long as I make appropriate
use of version statements to ensure
On 04/05/14 00:54, Joseph Rushton Wakeling wrote:
> Hello all,
>
> If we change the length of a dynamic array using the normal GC-based methods,
> e.g. by setting the array's .length property, we find that the array's
> capacity typically does not simply equal the length, but some greater value;
Joseph Rushton Wakeling:
Question: is there a comparable phenomenon for memory that is
manually allocated using malloc?
Manually allocated memory can over-allocate, but not
geometrically as arrays do.
Take a look at the difference between core.memory.extend and
core.memory.realloc.
Bye,
