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.

Lars Ivar Igesund

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.

On Mon, 20 Sep 2004 13:58:40 -0700, Burton Radons <burton-radons@shaw.ca> 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.

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;


If however the expression 'foo' modified arr.length you'd have a different story, so I assume that is what you meant?

In which case can't we rely on precedence rules applying i.e. the RHS is evaluated then the LHS or something.

I say this because I think arr.length++ is intuitive and therefore desirable.

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

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

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?



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.

Please, let's not argue this (again).  It's been argued at length - several times.  Check the old posts, in both this newsgroup and the older one.

DMD 0.101, Linux

The following code gives the error 'a.length is not an lvalue'.  This is obviously not true, since a.length is assignable.  A better message would be something like

'a.length++' is not allowed, use 'a.length = a.length+1' instead.



> void foo() {
>   int[] a;
>   a.length = 2;
>   a.length++;
> }

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.
> 
> Lars Ivar Igesund

This is working as designed (see other posts), but the error message is misleading.  I posted a message about it in the bugs newsgroup.

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

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

In article <cinhpr$574$1@digitaldaemon.com>, Russ Lewis says...
>
>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?

I think the correct expression would be this:

arr[++arr.length - 1] = foo;

Which just reeks of undefined behavior.


Sean

Regan Heath wrote:

> 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].

Nope; the comp.lang.c FAQ has a whole section essentially devoted to the subject (http://www.eskimo.com/~scs/C-faq/s3.html).

> If however the expression 'foo' modified arr.length you'd have a different story, so I assume that is what you meant?

> In which case can't we rely on precedence rules applying i.e. the RHS is evaluated then the LHS or something.

Neither lvalue/rvalue nor precedence have any effect on order of evaluation; only the sequence point.

> I say this because I think arr.length++ is intuitive and therefore desirable.

I agree that it's a silly error, since it's not erroneous in most cases.   Making the compiler identify the special case the error was built for or introducing logic to discover undefined expressions (like GCC has) would be better.  That'll have to wait until after the bug fixes and the standard, though.