[Issue 3378] [tdpl] ++x should be an lvalue

d-bugmail at puremagic.com d-bugmail at puremagic.com
Thu Mar 4 05:12:29 PST 2010


http://d.puremagic.com/issues/show_bug.cgi?id=3378



--- Comment #8 from Andrei Alexandrescu <andrei at metalanguage.com> 2010-03-04 05:12:28 PST ---
(In reply to comment #7)
> testing:
> 
> [steves at steveslaptop ~]$ cat testit.c
> int x;
> int * foo()
> {
>     return &(++x);
> }
> [steves at steveslaptop ~]$ gcc -c testit.c
> testit.c: In function ‘foo’:
> testit.c:4: error: lvalue required as unary ‘&’ operand
> [steves at steveslaptop ~]$ g++ -c testit.c
> [steves at 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: -------


More information about the Digitalmars-d-bugs mailing list