www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - .length and lvalue?

reply Fredrik Olsson <peylow gmail.com> writes:
Is there a technical problem that hinders these constructs?
foo.length++;
++foo.length;
foo.length += 42;

For the first two I can see that refusing them would encourage the use 
of ~= to append to arrays, as in 9 of 10 cases the next line is probably 
an assignment of the last element.

But for the last one, I kind of guess that making one huge resize and 
then adding the elements can be fore effective (Unless the elements to 
add are in an array as well).

And does this have anything to do with this construct not working:
class Foo {
   private int _bar = 2;
   void bar(int newbar) { _bar = newbar; }
   int bar() { return _bar; }
}
int main(char[][] args) {
   Foo foo = new Foo;
   foo.bar++;		// Not a scalar
   ++foo.bar;		// --"--
   foo.bar += 1;		// --"--
   foo.bar = foo.bar + 1; // Well this works :)
   return 0;
}

I was under the impression that 'a+=1' was simply rewritten as 'a=a+1', 
but then I have never written a complete compiler myself :) (Only 
dabbled with a LISP interpreter).

regards
	Fredrik Olsson
Aug 22 2005
next sibling parent reply Manfred Nowak <svv1999 hotmail.com> writes:
Fredrik Olsson <peylow gmail.com> wrote in
news:deeh6r$2esr$1 digitaldaemon.com 

 Is there a technical problem that hinders these constructs?

From the specs: | Note: Properties currently cannot be the lvalue of an op=, ++, or -- operator. -manfred
Aug 23 2005
parent Fredrik Olsson <peylow gmail.com> writes:
Manfred Nowak skrev:
 Fredrik Olsson <peylow gmail.com> wrote in
 news:deeh6r$2esr$1 digitaldaemon.com 
 
 
Is there a technical problem that hinders these constructs?

[...] From the specs: | Note: Properties currently cannot be the lvalue of an op=, ++, or -- operator.

bugs :). I am more curious as to why this limitation has survived for so long. As I believe it may be a feature quite frequently asked for, and I read that at least ++foo is rewritten as foo += 1, so I assumed a further rewrite to foo = foo + 1, but I guess I was wrong on that account. So I was just curious if it is left because of philosophical reasons (such as encouraging ~=), or if there is a technical obstacle. Or perhaps no one have even thought of it before? ;) regards Fredrik Olsson
Aug 23 2005
prev sibling parent Derek Parnell <derek psych.ward> writes:
On Tue, 23 Aug 2005 08:54:07 +0200, Fredrik Olsson wrote:

 Is there a technical problem that hinders these constructs?
 foo.length++;
 ++foo.length;
 foo.length += 42;
 
 For the first two I can see that refusing them would encourage the use 
 of ~= to append to arrays, as in 9 of 10 cases the next line is probably 
 an assignment of the last element.
 
 But for the last one, I kind of guess that making one huge resize and 
 then adding the elements can be fore effective (Unless the elements to 
 add are in an array as well).
 
 And does this have anything to do with this construct not working:
 class Foo {
    private int _bar = 2;
    void bar(int newbar) { _bar = newbar; }
    int bar() { return _bar; }
 }
 int main(char[][] args) {
    Foo foo = new Foo;
    foo.bar++;		// Not a scalar
    ++foo.bar;		// --"--
    foo.bar += 1;		// --"--
    foo.bar = foo.bar + 1; // Well this works :)
    return 0;
 }

Yes, this is the reason that array.length can't be used as an lvalue. The length of an array is implemented as a 'property' which means that its a function call rather than a direct access of some RAM. So in effect array.length++; would be equivalent to array.length()++; which is not what you really want. If you look at your example int X = foo.bar; foo.bar = 2; is the same as int X = foo.bar(); foo.bar(2); and this means that 'foo.bar++' is the same as 'foo.bar()++' which is meaningless code (disregarding any side effects). foo.bar = foo.bar + 1; is the same as foo.bar( foo.bar + 1); Hope this helps.
 I was under the impression that 'a+=1' was simply rewritten as 'a=a+1', 
 but then I have never written a complete compiler myself :) (Only 
 dabbled with a LISP interpreter).

Unfortunately this is not the case with 'properties'. I hope that one day Walter can transparently get the compiler to recognize properties and really treat them as if they were member variables. It would make writing generic code a lot simpler. -- Derek Parnell Melbourne, Australia 24/08/2005 1:20:31 AM
Aug 23 2005