Fixing const arrays

[Peter Alexander]

On 14/12/11 8:59 PM, Steven Schveighoffer wrote:
> On Wed, 14 Dec 2011 15:39:55 -0500, Peter Alexander
> <peter.alexander.au at gmail.com> wrote:
>
>> On 14/12/11 8:16 AM, Timon Gehr wrote:
>>> On 12/14/2011 12:35 AM, Peter Alexander wrote:
>>>> On 13/12/11 11:11 PM, Timon Gehr wrote:
>>>>> On 12/14/2011 12:14 AM, Peter Alexander wrote:
>>>>>> On 13/12/11 10:17 PM, Vladimir Panteleev wrote:
>>>>>>> On Tuesday, 13 December 2011 at 21:10:22 UTC, Andrei Alexandrescu
>>>>>>> wrote:
>>>>>>>> There's a phrase in Romanian that quite applies: "From the lake
>>>>>>>> into
>>>>>>>> the well".
>>>>>>>
>>>>>>> I believe the English version is "Out of the frying pan, into the
>>>>>>> fire" :)
>>>>>>>
>>>>>>> Inconsequential space-filler opinion: I am OK with @property, mainly
>>>>>>> because it's a common feature among PLs, it's better than
>>>>>>> nothing, and
>>>>>>> don't know better solutions.
>>>>>>
>>>>>> In my opinion, it's not better than nothing.
>>>>>>
>>>>>> What it gives you:
>>>>>>
>>>>>> 1. A bit of syntactic sugar.
>>>>>> 2. The ability to refactor member look up easily.
>>>>>>
>>>>>> What it costs:
>>>>>>
>>>>>> 1. Overloads syntax.
>>>>>> a. obj.field can now be an arbitrary function call.
>>>>>> b. May have arbitrary cost (e.g. T[].length)
>>>>>
>>>>> ??? T[].length is a field access, not a property function. It takes a
>>>>> small constant amount of time.
>>>>
>>>> Assigning to the length of an array may reallocate it, which is not a
>>>> small, nor constant amount of time.
>>>>
>>>> int[] a;
>>>> ...
>>>> a.length = n; // may invoke a GC allocation + O(n) memcpy
>>>
>>> OK, I see, thanks. I don't think it is problematic in this particular
>>> case though.
>>
>> Well, it is a little. It makes it difficult to scan code looking for
>> GC allocations, or even scan code looking for inefficiencies.
>>
>> Obviously I know now that I have to look for .length assignments on
>> arrays, but it can be quite horrific when looking at code that uses
>> third party libraries that you aren't familiar with.
>>
>> An example of this I encountered in practice was in Unity3D's libraries.
>>
>> http://unity3d.com/support/documentation/ScriptReference/WWW-texture.html
>>
>> The WWW class has a 'texture' property. A small sentence in the middle
>> of its documentation reveals the horror.
>>
>> "Each invocation of texture property allocates a new Texture2D."
>>
>> That's right. Every time you read WWW.texture, it allocates a large
>> chunk of memory. In my particular case, I was copying the pixels from
>> the texture into another array, something like this:
>>
>> WWW www = ...;
>>
>> for (int i = 0; i < www.texture.width; ++i)
>> for (int j = 0; j < www.texture.height; ++j)
>> buffer[i][j] = www.texture.GetPixel(i, j);
>>
>> For a small 100x100 texture, that code allocates over 10,000, 100x100
>> textures.
>>
>> Luckily, that was horrific enough to prompt me to investigate, but a
>> less obvious problem would have likely slipped past me unnoticed.
>
> Yes, but length as a read property does not allocate anything (nor does
> reducing the length). In fact, length as a read property reduces to a
> field access (it is a language builtin, after all).

Length reading is fine.

> Would you expect that setting the length of an array to a *larger* size
> would not allocate? Your example shows something that doesn't look like
> it should be costly, but it actually is. Expanding length *looks* costly
> (and it is).

It's not that I wouldn't expect it (I would), but at a glance (i.e. 
without thinking about it) you wouldn't notice it. It just looks like a 
member assignment.

It's like overloading operator& in C++. It takes something that had one 
meaning and changes it into something else without a change in syntax. 
It's essentially the syntactic version of function hijacking.

> You do have a point that it shouldn't necessarily be a property. I also
> don't think dup, reverse, or sort should be array properties. But these
> are pieces of the language that have been there forever. To change them
> now would be disruptive for very little gain.

Agreed.