[c] invalid lvalue in decrement
 

The expression I am dealing with is

a += ---b--;

That is just a small portion of the statement but my job is to add parenthesis to enforce the implicit c precedence rules.

I haven't been able to come up with a way to make this work.
I keep getting the compile error invalid lvalue in decrement when I try things such as:
a = -(--(b--));
a = -((--b)--);
etc...

Any ideas why this won't run?

try:
a = a - (--(b--));
a = a - ((--b)--);
etc

how about:
a += -(-(-(b--)))

i believe its because the addition of the parenthesies are forcing it to parse in an order it doesn't like. why can't you just change the code to look and work simply instead of being complex? KISS.
a += -(b-2);
a += (-(b-1))-1;

Because this is probably a homework question that he doesn't want to solve himself. Dude, read the book and learn something. Go ask your prof. Getting a "free" answer on TFP isn't going to help you learn to be a better programmer.

Go find a copy of
Deep C Secrets.
It's in there somewhere, with a really good explaination.

What if you do something like this:

(a += -(-(-(b--))));

I think CSflim has it right. It's been a while since I've done any work in C. Also, skaven, why is it better for him to get an answer from his prof then from some other coders here at the TFP? In fact, I bet some of us are probably better programmers than the teacher, quadruply so if it's a high school assignment. I've been programming for >10 years in various languages, and I've encountered "teachers" that I've had to correct. I'm sure there are those here who have much more knowledge than me.

if this is a homework question then the school needs to find a new teacher. Using pre and post increment operators like that is very bad form. The only exception would be if the professor was trying to show that such a statement is bad form. Pre and post increment operators should only be used in simple statements to avoid obscure equations like above. Such an equation is a nightmare for debugging and code maintenance.

:lol: Yes let this be a lesson... instead of writing stupid crazy expressions that you need the C standard in front of you to figure out, write TOTALLY UNAMBIGUOUS READABLE CODE and then you don't have to WORRY about it. This isn't PERL. :lol: But that goes for Perl too! And this problem could still be useful for figuring out other programmers' totally ambiguous unreadable code...