Change representation of dynamic arrays?

[Kris]

Yeah, I'm with Steve on this. There's more than one way to skin this cat, 
and have solid performance all round instead of potentially trading one for 
another.


"Steven Schveighoffer" <schveiguy at yahoo.com> wrote in message 
news:ffij0u$290f$1 at digitalmars.com...
> "Walter Bright" wrote
>> 2) Doesn't break array.length as rvalue, as this is rewritten by the 
>> compiler as (array.end - array.start).
>
> Yes, but checking the length (which is something I do often in my code) 
> now becomes an operation rather than a memory load.  So you are swapping a 
> performance hit in one place with one in another.
>
>> What does this break?
>>
>> 1) Passing dynamic arrays to printf as in:
>>
>> printf("my string is %*.s\n", str);
>
> Absolutely could not care less :)
>
>>
>> So, what do you think?
>
> I think this change is unnecessary for iterators, why do we need to change 
> the array representation?  An iterator is a pointer in a sequence of 
> values. It does not need to know where in the sequence of values it is, so 
> why would you represent an iterator with 2 pointers?  If you make the case 
> that it's for bounds checking, then you really need 3 pointers to check 
> for reverse iterating past the beginning.  I'll also point out that you 
> are now adding the cost of copying two values when passing an iterator 
> around instead of one pointer, so using pointers will be faster anyways.
>
> Why not have an iterator type, defined as the property of an array, i.e.:
>
> char[].iterator is a type, which is aliased to char *.
>
> Then you could have properties like:
>
> char[].iterator begin() { return ptr}
> char[].iterator end() { return ptr + length}
>
> This is very similar to C++, and makes the most sense to me, and provides 
> the most speed out of anything.
> You could do something similar with AA's, but the type would have to be a 
> struct probably.
>
> It wouldn't even pollute the namespace/require keywords because they are 
> properties of the arrays themselves.
>
> -Steve
>