Very simple question

[DenisSolovov]

I have very simple question, look at next expression:
int b = 0;
int c = 0;
int d = b+++++c;
This expression make me to ask a few questions:

1) What value of d ?
2) Does it depend from used compilator: gcc, Visual Stuiod 7.1/8.0,
etc. ?
3) What behavior is correct according standard ANSI C, C++ ? Does
standard specify order of calculating operation ++.

 

[Victor Bazarov]

I have very simple question, look at next expression:
int b = 0;
int c = 0;
int d = b+++++c;
This expression make me to ask a few questions:

1) What value of d ?

The code isn't supposed to compile.

2) Does it depend from used compilator: gcc, Visual Stuiod 7.1/8.0,
etc. ?
3) What behavior is correct according standard ANSI C, C++ ? Does
standard specify order of calculating operation ++.

V

 

[Hn]

I have very simple question, look at next expression:
int b = 0;
int c = 0;
int d = b+++++c;
This expression make me to ask a few questions:

1) What value of d ?

b++ = b+1 = 1
b+++ = b+2 = 2
b++++ = b+3 = 3
b++++ +c = 3

so d=3.

 

[Victor Bazarov]

b++ = b+1 = 1
b+++ = b+2 = 2
b++++ = b+3 = 3
b++++ +c = 3

so d=3.

So, when we need to increment the value 33 times we should
write

value+++++++++++++++++++++++++++++++++

right?

V

 

[Guest]

I have very simple question, look at next expression:
int b = 0;
int c = 0;
int d = b+++++c;
This expression make me to ask a few questions:

As Victor said, it should not compile, however if you meant

int d = b++ + ++c;

then we can answer the questions below.

1) What value of d ?
1.

2) Does it depend from used compilator: gcc, Visual Stuiod 7.1/8.0,
etc. ?
No.

3) What behavior is correct according standard ANSI C, C++ ? Does
standard specify order of calculating operation ++.

I think (but I'm not sure) that both the C and C++ standards agree on
this one. C++ does not specify the order in which b++ and ++c are
evaluated, only that they should be evaluated before + and = are.

 

[Miguel Guedes]

I have very simple question, look at next expression:
int b = 0;
int c = 0;
int d = b+++++c;
This expression make me to ask a few questions:

1) What value of d ?
2) Does it depend from used compilator: gcc, Visual Stuiod 7.1/8.0,
etc. ?
3) What behavior is correct according standard ANSI C, C++ ? Does
standard specify order of calculating operation ++.

As Victor and others have pointed out that shouldn't compile. However it
compiles like so:

int d = (b++)+(++c);

 

[Michael DOUBEZ]

Victor Bazarov a écrit :

So, when we need to increment the value 33 times we should
write

value+++++++++++++++++++++++++++++++++

right?

wrong ! If value++ is value+1 then value+33 should have 34 '+'. You put
only 33. Must be a typo.

Just to answer the thread, b++++ shouldn't compile because b++ return a
non-lvalue then the second ++ cannot be applied.

Michael

 

[Barry]

Victor Bazarov a écrit :

wrong ! If value++ is value+1 then value+33 should have 34 '+'. You put
only 33. Must be a typo.

Just to answer the thread, b++++ shouldn't compile because b++ return a
non-lvalue then the second ++ cannot be applied.

Your arithmatic is good, but think about it, 34 * 2 (two + means
increment). should there should be 68 '+'.

;-)

 

[Victor Bazarov]

Your arithmatic is good, but think about it, 34 * 2 (two + means
increment). should there should be 68 '+'.

;-)

No, no, Michael is right. The number of pluses should be one more
than the increment (at least according to "Hn"s logic). My mistake
was not supplying the correct number of pluses (apparently).

V

 

[LR]

I have very simple question, look at next expression:
int b = 0;
int c = 0;
int d = b+++++c;
This expression make me to ask a few questions:

That won't compile. The parser is greedy, it thinks you're trying
something like (b++)++ and (b++) can't be incremented.

I think you meant:

int d = b++ + ++c;

1) What value of d ?

The value of b, c and d will all be one after that line executes.

2) Does it depend from used compilator: gcc, Visual Stuiod 7.1/8.0,
etc. ?

Assuming that all the compilers you've referenced are working, I don't
think that it will, however, suppose that your question was about:

int e = c++ + ++c;
or
int f = ++c+c++;

then I think you'd want to google about sequence points, here's a link
to get you started: http://en.wikipedia.org/wiki/Sequence_point here's
another:
http://angelikalanger.com/Articles/VSJ/SequencePoints/SequencePoints.html

LR

 

[LR]

That won't compile. The parser is greedy, it thinks you're trying
something like (b++)++ and (b++) can't be incremented.

I think you meant:

int d = b++ + ++c;



The value of b, c and d will all be one after that line executes.



Assuming that all the compilers you've referenced are working, I don't
think that it will, however, suppose that your question was about:

int e = c++ + ++c;
or
int f = ++c+c++;

then I think you'd want to google about sequence points, here's a link
to get you started: http://en.wikipedia.org/wiki/Sequence_point here's
another:
http://angelikalanger.com/Articles/VSJ/SequencePoints/SequencePoints.html

LR

Oops, replying to my own post here. Also, see the FAQ.
http://www.parashift.com/c++-faq-lite/misc-technical-issues.html#faq-39.15

LR

 

[Barry]

No, no, Michael is right. The number of pluses should be one more
than the increment (at least according to "Hn"s logic). My mistake
was not supplying the correct number of pluses (apparently).

Gotta learn that *logic* first before post, my bad

 

[Jerry Coffin]

I have very simple question, look at next expression:
int b = 0;
int c = 0;
int d = b+++++c;

Due to the 'maximum munch" rule, this is lexed as:

int d = b ++ ++ + c;

Since the first '++' returns an rvalue, the second one can't work, and
the expression doesn't compile.

If you want to be perverse, you can define a type for which ++ returns
an lvalue, and allow similar code to compile for that type:

class EVIL_LEAKY {
int value;
public:
EVIL_LEAKY(int v=0) : value(v) {}

EVIL_LEAKY &operator++(int) {
EVIL_LEAKY *temp = new EVIL_LEAKY;
temp->value=value;
value++;
return *temp;
}
operator int() { return value; }
};

#ifdef TEST
#include <iostream>

int main() {
EVIL_LEAKY b=0;
EVIL_LEAKY c=0;
int d = b+++++c;

std::cout << "d=" << d << "\n";
return 0;
}
#endif

As you might guess from its name, this class is definitely NOT an
example of recommended practice!

 

[Michael DOUBEZ]

Jerry Coffin a écrit :

Due to the 'maximum munch" rule, this is lexed as:

int d = b ++ ++ + c;

It has nothing to do with the "maximum munch", it is because
post-increment has a higher precedence than plus and pre-increment.

See http://www.cppreference.com/operator_precedence.html.

Since the first '++' returns an rvalue, the second one can't work, and
the expression doesn't compile.

If you want to be perverse, you can define a type for which ++ returns
an lvalue, and allow similar code to compile for that type:

class EVIL_LEAKY {
int value;
public:
EVIL_LEAKY(int v=0) : value(v) {}

EVIL_LEAKY &operator++(int) {
EVIL_LEAKY *temp = new EVIL_LEAKY;
temp->value=value;
value++;
return *temp;
}
operator int() { return value; }
};

Or without leak:

struct myInt
{
myInt(int i=0):i_(i){}

myInt& operator++(int){myInt r(*this);++i_;return r;}

operator int()const{return i_;}

private:
int i_;
};

pre-increment is a bit more tricky because you have to play with consteness.


Michael

 

[Michael DOUBEZ]

Michael DOUBEZ a écrit :

Or without leak:

struct myInt
{
myInt(int i=0):i_(i){}

myInt& operator++(int){myInt r(*this);++i_;return r;}

Oups typo:
myInt operator++(int){myInt r(*this);++i_;return r;}

operator int()const{return i_;}

private:
int i_;
};

pre-increment is a bit more tricky because you have to play with
consteness.

Or simply adding:
myInt& operator++(){++i_;return *this;}

Michael

 

[Pete Becker]

Jerry Coffin a écrit :

It has nothing to do with the "maximum munch", it is because
post-increment has a higher precedence than plus and pre-increment.

See http://www.cppreference.com/operator_precedence.html.

The language definition uses the maximum munch rule:

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, even if that would cause further lexical
analysis to fail. [lex.pptoken]/3.

It then discusses an example like the one above to illustrate the
consequences of this rule.

More generally, the language definition does not define operator
precedences. It provides syntax productions, and some people think it's
easier to express the meaning of those productions by writing their own
precedence tables.

And still more generally, operator precedence applies only after you
know what operators you're dealing with. It doesn't tell you how to
split +++++ into operators.

 

[Jerry Coffin]

Jerry Coffin a écrit :

It has nothing to do with the "maximum munch", it is because
post-increment has a higher precedence than plus and pre-increment.

Sorry, but you're just plain wrong. The precedence cannot be determined
until the characters have been tokenized -- and that's done by the
maximum munch rule.

See http://www.cppreference.com/operator_precedence.html.

It's utterly irrelevant here.

 

[James Kanze]

[...]

I think (but I'm not sure) that both the C and C++ standards
agree on this one. C++ does not specify the order in which b++
and ++c are evaluated, only that they should be evaluated
before + and = are.

It's even more subtle. An expression has 1) a value, and 2)
side effects. (The "value" may have type void, of course, and
the side effects may be a no-op. But neither is the case here.)
The standards (both C and C++) guarantee that the value will be
available before it is used (here, before the + is executed) and
that the side effects will take place before the following
(here, at the ';' which terminates the statement, more or less).