Fixing const arrays

[Timon Gehr]

On 12/14/2011 09:39 PM, Peter Alexander 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.
>

Oh yes, certainly. That is what I meant by 'in this particular case': 
Because the .length on arrays is built into the language, you know that 
it must allocate as soon as you have a sufficiently good mental model of 
how dynamic arrays work. (and anyone who wants to write effective D code 
that uses dynamic arrays should)

> 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.
>

oO. That is quite an API design problem there.