In the last episode (Aug 19), Dan Nelson said:

In the last episode (Aug 20), Martin Nilsson (DivX Networks) @ Pike (-) developers forum said:

...

Would it be possible and make sense to have the structures that supports over-allocation (such as arrays) to always use full malloc "quanta"?

I think it would be very difficult to determine exactly what that quanta might be. The only place I can see it helping is when growing an array by appending (so you aren't copying the whole thing every time). Would just extending the array by 50% work as well?

I didn't read array.c enough :) When resize_array has to grow an array, it already allocates 50% more space than necessary, and most of the other array-allocation routines do also.

If you change the size of an array, references are always lost.

/ Martin Nilsson (DivX Networks)

Previous text:

2004-09-10 01:44: Subject: growing arrays (was: array.c)

---

how does one resize an array on the pike level? when i append to an array (+=) then the array is essentially copied, which means a new array is created and references are broken. that doesn't look like resizing to me (although it might be at the c level)

where does resize_array come into effect?

greetings, martin.

/ Brevbäraren

Keep in mind that

a += b;

is actually just a shorthand for

a = a + b;

So, nothing is done to the array previously referenced by a. All that happens is that the variable a is rebound to a new value, which is the result of the computation a+b. Of course, this computation should not alter the old array either, if there are references to it.

This is different from

a[0] = x;

which modifies the contents of the array referenced by a. Since arrays are reference types, this will also affect other references to the same object.

The difference is made clear from the following example:

mixed foo() { return a; }

void bar() { foo()[0] = x; // Ok, modifies the array referenced by a foo() = foo() + b; // Not ok. The "resized" array can be computed, // but not assigned back to a (or any other // variables referencing the same array) }

As for things happening on the C level, the computation a+b actualy _does_ modify the array referenced by a destructively, _iff_ there are no additional references to it. Thus you can get efficient resizing of arrays, even while maintaining the semantics described above.

If you want multiple references to an array which changes size, this can be accomplished by wrapping the array in another reference type, such as an object. Since the object will contain the only reference to the array, it can be resized efficiently, and all code which holds a reference to the object will be able to access the new array.

If one really wanted, it would be possible to make a function that destructively resizes an array regardless of the number of references (just as there are functions like m_delete() which destructively modifies mappings), however there is at least one thing which would have to be changed in the implementation in that case: Currently the empty array ({}) is shared since it is immutable. If one were able to alter the empty array in any way it would have to be instantiated anew for each time ({}) occurs in code. Apart from increased memory and time overhead, this would also create a backwards incompatibility on the C level.

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

Previous text:

2004-09-10 02:14: Subject: Re: growing arrays (was: array.c)

---

yes, so it appears. but is that a sideeffect of something happening on the c-level that would be costly to change, or is it simply a design decision that could be changed codewise. (i am aware that this would probably break compatibility)

greetings, martin.

/ Brevbäraren

Actually, your "reference" type exists internally in Pike, it is used for sscanf(). :-) (There is no way of using it except from C code of course.)

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

Previous text:

2004-09-10 16:22: Subject: Re: growing arrays (was: array.c)

---

you guys are great, this is the stuff i have been looking for.

On Fri, Sep 10, 2004 at 11:20:02AM +0200, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:

...

Keep in mind that a += b; is actually just a shorthand for a = a + b;

So, nothing is done to the array previously referenced by a.

i was aware of that. this is what got me wondering what all thit talk about growing arrays is about, when you can't actually grow them.

...

As for things happening on the C level, the computation a+b actualy _does_ modify the array referenced by a destructively, _iff_ there are no additional references to it.

ahhh, that's the secret.

...

If one really wanted, it would be possible to make a function that destructively resizes an array regardless of the number of references

i just had the scary thought of solving this with a new "reference" type: (probably not a good idea)

array bar; reference foo=refernce(bar); // references are constant reference foo=bar; // i like this one better, otherwise it would be // possible to create references of references foo=({ 2 }); // any changes after the instantiation change the // referd variable foo+=({ 1 }); // also changes bar

greetings, martin.

/ Brevbäraren