In article <opsenbajbk5a2sq9@digitalmars.com>,
 Regan Heath <regan@netwin.co.nz> wrote:

> On Mon, 20 Sep 2004 14:24:10 -0700, Russ Lewis <spamhole-2001-07-16@deming-os.org> wrote:
> > Regan Heath wrote:
> >>> It was introduced to prevent:
> >>>
> >>>     arr [arr.length ++] = foo;
> >>>
> >>> Which has an undefined result.
> >>
> >> I don't think that has an undefined result, AFAIKS:
> >>
> >> - the value of arr.length is taken (L)
> >> - arr.length is incremented.
> >> - foo is assigned to arr[L].
> >>
> >> eg.
> >>
> >> L = arr.length;
> >> arr.length++;
> >> arr[L] = foo;
> >
> > Since it's post increment, isn't the sequence actually:
> > 	arr[arr.length] = foo;
> > 	arr.length = arr.length + 1;
> > which is obviously broken because you're exceeding the bounds of the
> > array?
> 
> Oops, yes, you're right.
> 
> In that case this restriction does stop this particular bug. Why is:
> 
>    arr.length += 100;
> 
> restricted? it's probably the more useful of the two.
> 
> > Anyhow, what Walter has said is that he doesn't want to have
> > 	arr.length++;
> > because it makes it look like setting .length is as simple as addition,
> > when actually it's a call to a fairly complex function.
> 
> Sure, but I don't think forcing people to use arr.length = arr.length + 1 causes anyone to realise that. More likely they just think WTF?! why can't I use arr.length++; I know I did.
> 
> > Please, let's not argue this (again).  It's been argued at length - several times.
> 
> What that pun/joke intentional?
> 
> > Check the old posts, in both this newsgroup and the older one.
> 
> Ok, but can you answer my little question above and same me/everyone who does not know already the trouble of searching.
> 
> Thanks in advance.
> 
> Regan

I think it's rather silly that a so called attribute has a special behavior here.  It should be obvious that it's a function and not an lvalue if it is indeed a function.

arr.setLength() or something would be much clearer.

Because arr.length = arr.length + 1 makes it look like it's simple addition.....

Sjoerd van Leent wrote:
> Burton Radons wrote:
> 
>> Lars Ivar Igesund wrote:
>>
>>> Why do
>>>
>>> arr.length = arr.length + 1;
>>>
>>> work when
>>>
>>> arr.length += 1;
>>>
>>> and
>>>
>>> arr.length++;
>>>
>>> don't ("arr.length is not an lvalue")?
>>> AFAIK, arr.length is an lvalue in the first statement, too.
>>
>>
>>
>> It was introduced to prevent:
>>
>>    arr [arr.length ++] = foo;
>>
>> Which has an undefined result.
> 
> 
> It seems also that arr.length++ is rather pointless, because when adding a new item to an array, it can be done with the append operator:
> 
> int main (char[][] args) {
> 
>     byte[] ba;
>         for(byte b = 0; b < 10; b++) {
>         ba ~= b;
>     }
> 
>     // prints bytes: 0 1 2 3 4 5 6 7 8 9       printf("bytes: ");
>     foreach(byte b; ba) {
>         printf("%d ", b);
>     }
>     printf(\n);
>         return 1;
> }
> 
> Regards,
> Sjoerd

Read "Setting Dynamic Array Length" here:
http://www.digitalmars.com/d/arrays.html

Lars Ivar Igesund

Regan Heath wrote:
>> Anyhow, what Walter has said is that he doesn't want to have
>>     arr.length++;
>> because it makes it look like setting .length is as simple as addition, when actually it's a call to a fairly complex function.
> 
> Sure, but I don't think forcing people to use arr.length = arr.length + 1 causes anyone to realise that. More likely they just think WTF?! why can't I use arr.length++; I know I did.

>> Please, let's not argue this (again).  It's been argued at length - several times.
> 
> What that pun/joke intentional?

No, but I wish it had been! :)

>> Check the old posts, in both this newsgroup and the older one.
> 
> Ok, but can you answer my little question above and same me/everyone who does not know already the trouble of searching.

Well, you're not the first to state this viewpoint.  I, for one, agree with you.  But only Big W can make the final language decisions.

One thing in favor of his position, though, is that we could add support for the syntax later.  If Walter allowed it now and we decided later that it was a bad idea, it would be almost impossible to remove from the language.

In article <cipnh7$1g5n$1@digitaldaemon.com>, Russ Lewis says...
>
>Regan Heath wrote:
>>> Anyhow, what Walter has said is that he doesn't want to have
>>>     arr.length++;
>>> because it makes it look like setting .length is as simple as
>>> addition, when actually it's a call to a fairly complex function.
>> 

Currently, dynamic arrays are composed of a:
"length" and a "pointer to the array data".

I've thought, what if we used this implementation?:

"reserved length" -> "array length" -> "pointer to the array data"
NOTE: ("reserved" is recommended to be a power of 2, and always >= array length)

This implementation would increase the overhead of the array definition and probably break backwards compatibility, yet in most cases this would make concatenation a child's play in most cases, as you could do like this example:

int[] a=new int[14]; //reserved=32(amount decided by the compiler), length=14, pointer=(somewhere)

int b=a[15]; //Error, Out Of Bounds

array.length=19; //Allocate memory? naaah! two CPU instructions and done! :)
//reserved=32, length 19, pointer=(somewhere)

array.length++; //(length+1)< reserved, so we got another cheap resize ;)
//reserved=32, length 20, pointer=(somewhere)

array.length=80;
// (80 > reserved) Memory allocation is needed...the typical slow resize :( .
// reserved=128, length 80, pointer=(whatever)

array.reserved=5; //lol, nice hack attempt, but no. You can't access this.


What do you say?

In article <ciq8jb$2nd8$1@digitaldaemon.com>, Id says...

>Currently, dynamic arrays are composed of a:
>"length" and a "pointer to the array data".
>
>I've thought, what if we used this implementation?:
>
>"reserved length" -> "array length" -> "pointer to the array data" NOTE: ("reserved" is recommended to be a power of 2, and always >= array length)

So what structure would a[1..4] return?



>This implementation would increase the overhead of the array definition and probably break backwards compatibility, yet in most cases this would make concatenation a child's play in most cases, as you could do like this example:
>
>int[] a=new int[14]; //reserved=32(amount decided by the compiler), length=14, pointer=(somewhere)
>
>int b=a[15]; //Error, Out Of Bounds
>
>array.length=19; //Allocate memory? naaah! two CPU instructions and done! :)
>//reserved=32, length 19, pointer=(somewhere)

Which two, exactly?


>array.length++; //(length+1)< reserved, so we got another cheap resize ;)
>//reserved=32, length 20, pointer=(somewhere)
>
>array.length=80;
>// (80 > reserved) Memory allocation is needed...the typical slow resize :( .
>// reserved=128, length 80, pointer=(whatever)
>
>array.reserved=5; //lol, nice hack attempt, but no. You can't access this.

Yes you can. A union does the trick nicely.


>What do you say?

Did you forget about:
#    int[] a = new int[5];
#    int[] b = a;
#    a.length = 6;
#    a[5] = 100;
#    b.length = 6;  // What is b[5] now? Come to that, what is a[5]?

I think it would break way too much.
Jill