Why doesn't a+++++b work?

前端 未结 9 1002
悲&欢浪女
悲&欢浪女 2020-11-22 06:26
int main ()
{
   int a = 5,b = 2;
   printf(\"%d\",a+++++b);
   return 0;
}

This code gives the following error:

error: lval

相关标签:
9条回答
  • 2020-11-22 07:08

    Follow this precesion order

    1.++ (pre increment)

    2.+ -(addition or subtraction)

    3."x"+ "y"add both the sequence

    int a = 5,b = 2; printf("%d",a++ + ++b); //a is 5 since it is post increment b is 3 pre increment return 0; //it is 5+3=8

    0 讨论(0)
  • 2020-11-22 07:14
    (a++)++ +b
    

    a++ returns the previous value, a rvalue. You can't increment this.

    0 讨论(0)
  • 2020-11-22 07:14

    Because it causes undefined behaviour.

    Which one is it?

    c = (a++)++ + b
    c = (a) + ++(++b)
    c = (a++) + (++b)
    

    Yeah, neither you nor the compiler know it.

    EDIT:

    The real reason is the one as said by the others:

    It gets interpreted as (a++)++ + b.

    but post increment requires a lvalue (which is a variable with a name) but (a++) returns a rvalue which cannot be incremented thus leading to the error message you get.

    Thx to the others to pointing this out.

    0 讨论(0)
  • 2020-11-22 07:19

    printf("%d",a+++++b); is interpreted as (a++)++ + b according to the Maximal Munch Rule!.

    ++ (postfix) doesn't evaluate to an lvalue but it requires its operand to be an lvalue.

    ! 6.4/4 says the next preprocessing token is the longest sequence of characters that could constitute a preprocessing token"

    0 讨论(0)
  • 2020-11-22 07:23

    This exact example is covered in the draft C99 standard(same details in C11) section 6.4 Lexical elements paragraph 4 which in says:

    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. [...]

    which is also known as the maximal munch rule which is used in in lexical analysis to avoid ambiguities and works by taking as many elements as it can to form a valid token.

    the paragraph also has two examples the second one is an exact match for you question and is as follows:

    EXAMPLE 2 The program fragment x+++++y is parsed as x ++ ++ + y, which violates a constraint on increment operators, even though the parse x ++ + ++ y might yield a correct expression.

    which tells us that:

    a+++++b
    

    will be parsed as:

    a ++ ++ + b
    

    which violates the constraints on post increment since the result of the first post increment is an rvalue and post increment requires an lvalue. This is covered in section 6.5.2.4 Postfix increment and decrement operators which says (emphasis mine):

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

    and

    The result of the postfix ++ operator is the value of the operand.

    The book C++ Gotchas also covers this case in Gotcha #17 Maximal Munch Problems it is the same problem in C++ as well and it also gives some examples. It explains that when dealing with the following set of characters:

    ->*
    

    the lexical analyzer can do one of three things:

    • Treat it as three tokens: -, > and *
    • Treat it as two tokens: -> and *
    • Treat it as one token: ->*

    The maximal munch rule allows it to avoid these ambiguities. The author points out that it (In the C++ context):

    solves many more problems than it causes, but in two common situations, it’s an annoyance.

    The first example would be templates whose template arguments are also templates (which was solved in C++11), for example:

    list<vector<string>> lovos; // error!
                      ^^
    

    Which interprets the closing angle brackets as the shift operator, and so a space is required to disambiguate:

    list< vector<string> > lovos;
                        ^
    

    The second case involves default arguments for pointers, for example:

    void process( const char *= 0 ); // error!
                             ^^
    

    would be interpreted as *= assignment operator, the solution in this case is to name the parameters in the declaration.

    0 讨论(0)
  • 2020-11-22 07:24

    Your compiler desperately tries to parse a+++++b, and interprets it as (a++)++ +b. Now, the result of the post-increment (a++) is not an lvalue, i.e. it can't be post-incremented again.

    Please don't ever write such code in production quality programs. Think about the poor fellow coming after you who needs to interpret your code.

    0 讨论(0)
提交回复
热议问题