http://d.puremagic.com/issues/show_bug.cgi?id=3378
--- Comment #8 from Andrei Alexandrescu <[email protected]> 2010-03-04 05:12:28 PST --- (In reply to comment #7) > testing: > > [ste...@steveslaptop ~]$ cat testit.c > int x; > int * foo() > { > return &(++x); > } > [ste...@steveslaptop ~]$ gcc -c testit.c > testit.c: In function ‘foo’: > testit.c:4: error: lvalue required as unary ‘&’ operand > [ste...@steveslaptop ~]$ g++ -c testit.c > [ste...@steveslaptop ~]$ > > So, C (at least in gcc) does not consider ++x an lvalue, C++ (g++) does. > > This is consistent with what Walter says. Choosing one or the other is > arbitrarily right or wrong depending on what compatibility you wish to have. > > I agree that defining ++x to be equivalent x+=1 for all types of x is bad, but > defining it that way for builtins is fine. > > I don't see a huge benefit to having ++x return an lvalue. Why can't you > rewrite bump like so? > > ref int bump(ref int x) { ++x; return x;} > > This should work for all types of x. > > In practice, I don't think using ++x as an lvalue comes up much. I can't rewrite bump because it's part of a large example illustrating ref. The book is in copyediting now and I must limit changes as much as possible. All other things equal, lvalue is better because there's less rewrite needed. One extra point to keep in mind: making ++x an lvalue makes compatible implementations for UDTs' ++ cheaper. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
