+++i

[kal]

Wrong. Precedence has nothing to do with it. It is parsed as:
++ +i
and as such malformed. (Some compilers allow it, gcc is one of them.)

Is +i an lvalue?

The compiler on this machine (MS VC 6.0) accepts "vone = +++vthree;"
but throws the following error for "vone = ++-vthree;"

error C2105: '++' needs l-value

Notes:

 

[CBFalconer]

.... snip ...
--
"...Almost makes you wonder why Heisenberg didn't include postinc/
dec operators in the uncertainty principle. Which of course makes
the above equivalent to Schrodinger's pointer..."
--Anthony McDonald

I didn't realize that Schrodinger had a dog. Is it in there with
the cat, or do they have separate boxes?

 

[Kenneth Brody]

A final remark:

a = b+++i;

is a valid expression (meaning it will most likely compile just fine)

Yep, assuming the variables have the appropriate types.

but the result is undefined (meaning it will most likely crash if you
run it on certain architectures)

I don't see that.

He's under the mistaken impression that the above is equivalent to

a = b + ++i;

which produces undefined behavior, rather than the actual

a = b++ + i;

which is well-defined.

[...]

 

[Keith Thompson]

Is +i an lvalue?
No.

The compiler on this machine (MS VC 6.0) accepts "vone = +++vthree;"
but throws the following error for "vone = ++-vthree;"

error C2105: '++' needs l-value

Notes:

It looks like MS VC 6.0 has a bug; apparently it treats +vthree as an
lvalue. (I wonder if it treates it as a modifiable lvalue; does it
complain about "++vthree = 42;")?

(BTW, +vthree isn't an lvalue in C++ either, so that's not the
problem.)

 

[Old Wolf]

My issue is that "+i" doesn't make sense.
1. If a zero (0) is placed in front:
0 + i;
This evaluates to just the value in 'i'.

2. The '+' in front does not change the sign of the variable.

This is the unary '+' operator. It's the same as the unary '-'
operator, except it doesn't change the sign of its operand's value.

I can't think of any practical use for it in C.

 

[Ben Pfaff]

This is the unary '+' operator. It's the same as the unary '-'
operator, except it doesn't change the sign of its operand's value.

I can't think of any practical use for it in C.

It is occasionally used for its side effect of changing an lvalue
to an rvalue (i.e. a non-lvalue). In turn, that tends to be used
in a macro that evaluates to the value of some object but
shouldn't be used to modify that object.

(Am I being too terse?)

 

[Dik T. Winter]

>
> Why not? I say it does.

It does not. See the excerpt from the standard by Dan Pop. In short,
tokenisation is performed before precedence is even considered.

> That is, these two operators have left to right precedence.

In what way does '++' have left to right precedence?

 

[Dik T. Winter]

>
> No. ....
> It looks like MS VC 6.0 has a bug; apparently it treats +vthree as an
> lvalue. (I wonder if it treates it as a modifiable lvalue; does it
> complain about "++vthree = 42;")?

(Of course you mean "+vthree = 42;" in the last line.) Whatever, gcc
2.95.2 allows that statement without an error message or warning.

 

[Dik T. Winter]

> This is the unary '+' operator. It's the same as the unary '-'
> operator, except it doesn't change the sign of its operand's value.
>
> I can't think of any practical use for it in C.

Actually at some stage in the development of one of the C standards it had
a practical use. At that stage "a + (b + c)" could be rearranged regardles
of whether it could change the result value or not. The unary plus was
introduced to disallow rearrangement when written as "a + +(b + c)". The
allowances for rearrangement were changed later (they are only allowed
when the result value of a valid expression would not change by the
rearrangement), but the unary plus was left in.

Having the unary plus is not so very useful in itself, but it allows for
cleaner display of tables (as in initialisations). Unlike original C,
all other programming languages I know do have it. Consider the following
initialisation in C:
double dc[] = {1.0,
-0.16666666666666666667,
0.00833333333333333333,
-0.00019841269841269841,
0.00000275573192239858,
-0.00000002505210838544,
0.00000000016059043836,
-0.00000000000076471637};
I would much have preferred it with unary plus.

 

[Keith Thompson]

...
It looks like MS VC 6.0 has a bug; apparently it treats +vthree as an
lvalue. (I wonder if it treates it as a modifiable lvalue; does it
complain about "++vthree = 42;")?

(Of course you mean "+vthree = 42;" in the last line.) Whatever, gcc
2.95.2 allows that statement without an error message or warning.[/QUOTE]

Yes, I meant "+vthree = 42;".

Later versions of gcc correctly reject it with error message
"error: invalid lvalue in assignment", the same message produced for
"42 = 42;".

(I might quibble about the wording; it's not an "invalid lvalue", it's
not an lvalue at all. There was a recent discussion in comp.std.c
about the standard's definition of "lvalue", but I don't think that's
what the gcc authors had in mind.)

 

[Ben Noordhuis]

This should teach me to not post at 5 o'clock in the morning after a
night of heavy drinking

You people were, of course, right where I was wrong.

 

[Dan Pop]

It is a semantic error, not a syntactic one. Thus, it is allowed
by the grammar, but disallowed by constraints.

The C grammar is not entirely specified by the syntax rules.
Those parts that were too difficult to be specified in the syntax
rules are specified as constraints, so constraint violations are not
necessarily semantic errors. Note that the semantic specifications
*always* follow the constraints.

For example, in C89, long long is a syntax error, although it doesn't
break any syntax rule; it is a constraint violation (3.5.2).

Dan

 

[Mark A. Odell]

It does not. See the excerpt from the standard by Dan Pop. In short,
tokenisation is performed before precedence is even considered.


In what way does '++' have left to right precedence?

With '+'. That is when one looks at the operators in the precedence
"level" with the '++' and unary '+' it says precedence is left to rigth,
so in an expression like this:

j = +++i;

I would have thought, reading left to right and being greedy we'd get

j = ++(+i);

which is illegal.

 

[Dan Pop]

I think you mean 'semantic error'.

I think you mean constraint violation.

Dan

 

[Dan Pop]

(Of course you mean "+vthree = 42;" in the last line.) Whatever, gcc
2.95.2 allows that statement without an error message or warning.

Even when invoked as a C compiler?

Dan

 

[Dan Pop]

This is the unary '+' operator. It's the same as the unary '-'
operator, except it doesn't change the sign of its operand's value.

I can't think of any practical use for it in C.

Imagine that you have a macro containing, at some point, the expression
a + b, where a and b are the macro parameters. The macro still works
(in C99 and in C89 implementations supporting empty macro arguments)
when invoked with a missing first argument, the binary + operator
becoming the unary + operator.

Other than that, it serves a purely esthetical purpose in certain
expressions and initialisers.

Dan

 

[Dan Pop]

With '+'. That is when one looks at the operators in the precedence
"level" with the '++' and unary '+' it says precedence is left to rigth,

Nope, it says *right to left* *associativity* and equal *precedence*
(according to K&R2, page 53).

But this is entirely irrelevant in a discussion about tokenisation...

Dan

 

[Keith Thompson]

Even when invoked as a C compiler?

Yes. (Not that it should matter; it's no more legal in C++ than in C.)

% uname -srp
SunOS 5.8 sparc
% cat tmp.c
#include <stdio.h>
int main(void)
{
int x = 0;
+x = 42;
printf("x = %d\n", x);
return 0;
}
% gcc --version
2.95.2
% gcc -ansi -pedantic -W -Wall tmp.c -o tmp
% ./tmp
x = 42

(It's not an operator precedence thing; changing "+x = 42;" to "(+x) = 42;"
makes no difference.)

The same bug occurs in several other gcc releases. It was fixed
some time between gcc 3.2 and 3.3.2.

 

[Dan Pop]

Yes. (Not that it should matter; it's no more legal in C++ than in C.)

It was C as opposed to GNU C (the default language compiled by gcc), not
C as opposed to C++.

Dan

 

[Keith Thompson]

It was C as opposed to GNU C (the default language compiled by gcc), not
C as opposed to C++.

Ah.