resizeable arrays: T[new]
Walter Bright
newshound1 at digitalmars.com
Mon Jun 4 12:55:16 PDT 2007
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.
More information about the Digitalmars-d-announce
mailing list