resizeable arrays: T[new]

Bruno Medeiros brunodomedeiros+spam at com.gmail
Sat Jun 9 08:47:07 PDT 2007


Walter Bright wrote:
> Sean Kelly wrote:
>> Walter Bright wrote:
>>> (The problem is if I pass a slice to a function, and then that 
>>> function reallocates the slice by changing the length or appending to 
>>> it, it can affect other slices into the same data in very 
>>> hard-to-explain ways.
>>
>> I'm not sure I understand how a reallocation could affect other slices 
>> into the same data.  If a reallocation occurs, that reallocation will 
>> be into entirely new memory, provided the slice doesn't start at the 
>> head of a memory block.  Is it the condition I just mentioned that's a 
>> problem?  If so, I suppose it is one way to trick the compiler into 
>> thinking the reference no longer refers to const data, when in fact it 
>> does.  If not, could you point me in the right direction?
> 
> Given:
> 
>     int[] a = new int[7];
>     int[] b = a[1..6];
>     b[1] = 2;   // writes through to a[2]
>     b.length = 4;
>     b[1] = 3;   // writes through to a[2]
>     b.length = 6;
>     b[1] = 4;   // does not write through to a[2]
> 
>>> Now, it turns out that it is very rare for a function to legitimately 
>>> want to resize a buffer passed to it. So we finally hit on the idea 
>>> of making a resizeable array a different type, say:
>>>
>>>    T[n]   a;  // static array
>>>    T[]    b;  // dynamic array
>>>    T[new] c;  // resizeable array
>>
>> Well, I think it is very rare for a function to want to resize an 
>> array that isn't passed by reference.  My first reaction would be to 
>> disallow resizing of non-ref array parameters entirely.  Since 
>> resizing may occur in place, this could be seen as a mutating 
>> operation on the underlying data.  If the user wants to resize a 
>> non-ref array parameter for local use he use assign ops and such.
> 
> That was my first reaction too, but Frits posted a reasonable use case.
> 
> 
>> I think this may be related to a question I've been avoiding until 
>> now: how will the new const features interact with struct and class 
>> member function use?  Will it always be legal to call member functions 
>> of const objects?  Will it never be legal?  Or perhaps there will be a 
>> way to label some operations as non-modifying (which suggests logical 
>> const)?
> 
> You'll only be able to call const member functions on const objects.


-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D



More information about the Digitalmars-d-announce mailing list