+++i

[kapilk]

Sir,

I dont know how to use this synatx is it valid and if at all how to use it

Thanks,

kapilk

 

[Thomas Matthews]

Sir,

I dont know how to use this synatx is it valid and if at all how to use it

Thanks,

kapilk

What are you trying to accomplish?

I understand that "++i" will increment the variable "i".
But I don't understand if the third '+' is a typo.
The expression "+i" does not make any sense by itself.

--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.comeaucomputing.com/learn/faq/
Other sites:
http://www.josuttis.com -- C++ STL Library book

 

[Kenneth Brody]

Sir,

I dont know how to use this synatx is it valid and if at all how to use it

By "this syntax", I am assuming you are referring to the "+++i" in your
subject line?

There is no such thing as "+++i" in C that I know of. What do you think
it's supposed to do? Perhaps you're thinking of "++i"?

 

[Mark A. Odell]

What are you trying to accomplish?

I understand that "++i" will increment the variable "i".
But I don't understand if the third '+' is a typo.
The expression "+i" does not make any sense by itself.

Greedy lexical analysis should "gobble" up operators based upon their
precedence. So +++i, I believe, is +(++i) which I suppose is the positive
result of 'i' incremented. I've seen this in binary expressions but not
unary, e.g.

k=j+++i;

Of course, spaces are quite powerful here in indicating intent as in:

k = j + ++i;

 

[Dik T. Winter]

> Greedy lexical analysis should "gobble" up operators based upon their
> precedence.

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

 

[Christopher Benson-Manica]

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 that specified by the grammar...?

 

[Mark A. Odell]

Wrong. Precedence has nothing to do with it.

Why not? I say it does.

It is parsed as:
++ +i
and as such malformed. (Some compilers allow it, gcc is one of them.)

Which is exactly as the precedence has it (I just mis-read the direction).
That is, these two operators have left to right precedence. So, the
expression must be parsed ++ (+i) since C uses greedy lexical analysis.
Had I only remembered that left was on the left instead of the right!

 

[Chris Dollin]

Greedy lexical analysis should "gobble" up operators based upon their
precedence.

Then it wouldn't be "greedy". The point of the term is exactly that
the lexer will eat as much as it can before it has to give up, without
caring that it might get sick later.

 

[Dan Pop]

Is that specified by the grammar...?

Try to be more explicit in your questions. Are you asking about the
parsing or about why ++ +i is an error?

For the parsing part:

6.4p4:

4 If the input stream has been parsed into preprocessing tokens
up to a given character, the next preprocessing token is
the longest sequence of characters that could constitute a
preprocessing token.

Therefore, +++i is tokenised as ++ + i, which is parsed as ++(+i), which
is a constraint violation:

6.5.3.1 Prefix increment and decrement operators

Constraints

1 The operand of the prefix increment or decrement operator shall
have qualified or unqualified real or pointer type and shall be
a modifiable lvalue. ^^^^^^^^^^^^
^^^^^^^^^^^^^^^^^^^

The result of the unary + operator is not a modifiable lvalue.

Dan

 

[Thomas Matthews]

Greedy lexical analysis should "gobble" up operators based upon their
precedence. So +++i, I believe, is +(++i) which I suppose is the positive
result of 'i' incremented. I've seen this in binary expressions but not
unary, e.g.

k=j+++i;

Of course, spaces are quite powerful here in indicating intent as in:

k = j + ++i;

That's nice, but not my issue.

If we have the statement:
+++i;
One of the '+' is applied to the variable 'i' (regardless of grouping
or precedence) as in:
+i;

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.

So as a stand-alone expression "+++i" doesn't make sense.

In another context, as you have pointed out, it does have
meaning.

Perhaps the OP would gives some more context around the issue.

--
Thomas Matthews

C++ newsgroup welcome message:
http://www.slack.net/~shiva/welcome.txt
C++ Faq: http://www.parashift.com/c++-faq-lite
C Faq: http://www.eskimo.com/~scs/c-faq/top.html
alt.comp.lang.learn.c-c++ faq:
http://www.comeaucomputing.com/learn/faq/
Other sites:
http://www.josuttis.com -- C++ STL Library book

 

[Arthur J. O'Dwyer]

The expression '+i' takes the value of 'i', performs the integral
promotions on it, and returns the new value. It might be useful
in writing macros, since '(int)i' would be wrong for 'long int' values
and '(long)i' would be wasteful for shorter values.

Wrong, of course. Read about "maximal munch." I'm almost positive
it's a FAQ.

So +++i, I believe, is +(++i)

Wrong.

which I suppose is the positive

Here we have 'k = j++ + i;', which is perfectly valid, though
obfuscated, C code. This is very different from the OP's example,
though.

Yes; in fact, in this case the whitespace changes the meaning of
the expression. So it's a good thing you "indicated" your intent with
whitespace; otherwise the compiler would have done what you /wrote/,
rather than what you /intended/!

[Thomas wrote:]

That's nice, but not my issue.

If we have the statement:
+++i;
One of the '+' is applied to the variable 'i' (regardless of grouping
or precedence) as in:
+i;

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.

s/variable/value/, obviously. As to why this is useful, see above.

So as a stand-alone expression "+++i" doesn't make sense.

Well, of course not! '+++i' is a syntax error, because '+i' does
not yield an lvalue. It's simply not valid C code.

-Arthur

 

[Benjamin Ketcham]

The expression "+i" does not make any sense by itself.

Sure it does. "+" can be a unary operator.

 

[Ben Noordhuis]

(e-mail address removed) (kapilk) wrote in message
Plain

+++i;

doesn't make sense but an expression like this is valid:

a = b+++i;

What it does? It increments /i/ with one, adds the result to the value
of /b/ and puts the result of the addition in /a/. If you want to show
off to your friends write code like this:

a = b+++++i;

This does the same as the former expression but it also increments /b/
after the result of /b/ + /++i/ has been put in /a/.

A final remark:

a = b+++i;

is a valid expression (meaning it will most likely compile just fine)
but the result is undefined (meaning it will most likely crash if you
run it on certain architectures) because the ANSI C Standard doesn't
say anything about the order in which the different parts of the
expression are evaluated.
A compiler could break it up like this:

int *temp;
temp = a + i;
++i;
*temp = b + i;

But it might just as well roll out like this:

int *temp;
++i;
temp = a + i;
*temp = b + i;

Hope this helps.

 

[Ben Pfaff]

Is that specified by the grammar...?

It is a semantic error, not a syntactic one. Thus, it is allowed
by the grammar, but disallowed by constraints. In particular,
the unary plus operator yields a value that is not a lvalue, but
the prefix increment operator's operand must be an lvalue.

 

[Kenneth Brody]

Ben Noordhuis wrote:
[...]

Plain

+++i;

doesn't make sense

True. It's also invalid, as it is equivalent to:

++ +i;

and "+i" is not an lvalue.

but an expression like this is valid:

a = b+++i;

What it does? It increments /i/ with one, adds the result to the value
of /b/ and puts the result of the addition in /a/.

Wrong! It is equivalent to:

a = b++ + i;

If you want to show
off to your friends write code like this:

a = b+++++i;

This does the same as the former expression but it also increments /b/
after the result of /b/ + /++i/ has been put in /a/.

Wrong! It is equivalent to:

a = (b++)++ + i;

which is illegal as "b++" is not an lvalue.

A final remark:

a = b+++i;

is a valid expression (meaning it will most likely compile just fine)
but the result is undefined (meaning it will most likely crash if you
run it on certain architectures) because the ANSI C Standard doesn't
say anything about the order in which the different parts of the
expression are evaluated.

It most certainly does specify the order. It requires it to be parsed as:

a = b++ + i;

which has no undefined behavior.

A compiler could break it up like this:

int *temp;
temp = a + i;
++i;
*temp = b + i;

No, it cannot, as the "++" *must* be applied to "b", and not "i".

[...]

Hope this helps.

I don't think it did. ;-)

 

[Christopher Benson-Manica]

4 If the input stream has been parsed into preprocessing tokens
up to a given character, the next preprocessing token is
the longest sequence of characters that could constitute a
preprocessing token.

That's what I was wondering about - thanks.

 

[Dave Vandervies]

(e-mail address removed) (kapilk) wrote in message
news:<[email protected]>...

[Nothing quoted in the article to which I'm replying]

Plain

+++i;

doesn't make sense

Sure it does. The tokenizer will always convert a string of +s into a
string of increment operators with (if there's an odd number) a single +
operator at the end, so this parses "sensibly" as `increment the result
of applying the unary + operator to i', but this is not permitted since
+i doesn't yield an lvalue, which gives us a constraint violation.
(GCC fails to diagnose this, incidentally; it treats +i as identical to i:
--------
dave@hct-cvs:~/clc (0) $ cat foo.c
int main(void)
{
int i;
(+i)=1; /*line 4*/
(-i)=1; /*line 5*/
return 0;
}
dave@hct-cvs:~/clc (0) $ gcc -W -Wall -ansi -pedantic -O -c foo.c
foo.c: In function `main':
foo.c:5: invalid lvalue in assignment
dave@hct-cvs:~/clc (1) $
--------
+i and -i should be treated exactly the same syntactically.)

but an expression like this is valid:

a = b+++i;

What it does? It increments /i/ with one, adds the result to the value
of /b/ and puts the result of the addition in /a/.

No. It tokenizes as `a = b ++ + i ;', which postincrements b, adds the
result of b++ (the old value of b) to i, and stores that in a:
--------
dave@hct-cvs:~/clc (0) $ cat foo.c
#include <stdio.h>

int main(void)
{
int a,b,i;
a=1;
b=2;
i=3;

printf("Initial values: a=%d,b=%d,i=%d\n",a,b,i);
a=b+++i;
printf("After `a=b+++i': a=%d,b=%d,i=%d\n",a,b,i);

return 0;
}
dave@hct-cvs:~/clc (0) $ gcc -W -Wall -ansi -pedantic -O foo.c
dave@hct-cvs:~/clc (0) $ ./a.out
Initial values: a=1,b=2,i=3
After `a=b+++i': a=5,b=3,i=3
dave@hct-cvs:~/clc (0) $
--------

If you want to show
off to your friends write code like this:

If you *really* want to show off, you can even come up with a way to do
this correctly.

a = b+++++i;

This does the same as the former expression but it also increments /b/
after the result of /b/ + /++i/ has been put in /a/.

Nope. This tokenizes as `a = b ++ ++ + i ;', which is an error (the
second ++ has no valid lvalue to be applied to).

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.

because the ANSI C Standard doesn't
say anything about the order in which the different parts of the
expression are evaluated.

And where is the order relevant here?

A compiler could break it up like this:

int *temp;
temp = a + i;
++i;
*temp = b + i;

But it might just as well roll out like this:

int *temp;
++i;
temp = a + i;
*temp = b + i;

A correct C compiler can do neither of these. A C compiler will *always*
do the equivalent of this:

--------
/*a=b+++i;*/
{
/*All of these operations happen between sequence points.
Order is not guaranteed, but the lack of order-dependencies
means that reordering won't be observable.
*/
int newb=b+1;
int oldb=b;
int temp1=oldb+i;
int *temp2=a+i;
b=newb;
*temp2=temp1;
}

 

[CBFalconer]

.... snip ...

Greedy lexical analysis should "gobble" up operators based upon
their precedence. So +++i, I believe, is +(++i) which I suppose
is the positive result of 'i' incremented. I've seen this in

You have it backwards. The greedy analysis produces:

++ (+i)

which is a syntax error.

 

[SM Ryan]

Unless you intend to write obscure code, +(++i) will be more easily comprehended
by anyone else coming along. Note that ++(+i) is an error.

 

[Alex Monjushko]

You have it backwards. The greedy analysis produces:

++ (+i)

which is a syntax error.

I think you mean 'semantic error'.