Change representation of dynamic arrays?

[BCS]

Reply to Bill,

> Jascha Wetzel wrote:
> 
>> Janice Caron wrote:
>> 
>>> On 10/20/07, Jascha Wetzel <firstname at mainia.de> wrote:
>>> 
>>>> Walter Bright wrote:
>>>> 
>>>>> Janice Caron wrote:
>>>>> 
>>>>>> That said, someone posted that you always allocate an extra byte.
>>>>>> If that's true, problem solved.
>>>>>> 
>>>>> Yes, an extra byte is allocated for just this reason.
>>>>> 
>>>> couldn't the end pointer just point to the last element?
>>>> 
>>> Oooh yuk. How horrible. I'd rather that didn't happen. For one
>>> thing, it means that empty arrays (and empty collection ranges
>>> generally) would have to have a different representation.
>>> 
>>> No, I like the "standard" way of doing things, whereby the end
>>> iterator refences the last+1 element (and therefore cannot be
>>> dereferenced).
>>> 
>> one can argue, that this way, empty arrays have an unambiguous
>> representation (they are always null).
>> there is enough code like
>> if ( str is null || str == "" )
>> which wouldn't be necessary.
>> the current semantics deal with null arrays in the same way as with
>> empty arrays (length == 0, appending works alike).
> Not quite true.  if(str){} tests only the .ptr part and ignores the
> length (as I quite painfully discovered recently... Sure wish there
> were an easy way to find all the places in my code where I used that
> expression instead of .length==0.).
> 
> --bb
> 

Ohh. That's another feature for an IDE: Find this pattern in the syntax/semantic 
tree.