-3
val = n++ + arr[n];

How can I rewrite the line of code above to become more readable? How is this code evaluated by a compiler?

Abdel Aleem
  • 667
  • 10
  • 15
  • You might as well rewrite it `char *k = NULL; k[2356] = 7` The runtime error will hide fewer bugs. – William Pursell Mar 17 '21 at 11:00
  • `How is this code evaluated by a compiler?` Order of operations is undefined by the C standard, so it depends on your compiler. `How can I rewrite the line of code` There is not one way to rewrite it, so it depends on the answer on the other question. You can also ask the original writer of that line of code what they originally meant. – xhienne Mar 17 '21 at 11:07
  • You could do this: `val = n+1 + arr[rand() % 2 + n]; n++;` – klutt Mar 17 '21 at 11:12
  • Dunno. What is it supposed to do? – Martin James Mar 17 '21 at 11:22
  • As the behavior is undefined or unspecified, we cannot deduct from the code what result you will see with your compiler. You (or the original programmer) should define what result is expected, then it is possible to write correct code that does what you want. – Bodo Mar 17 '21 at 11:23
  • 1
    See [Why can't we mix increment operators like i++ with other operators?](https://software.codidact.com/posts/278384). – Lundin Mar 17 '21 at 12:44
  • Arithmetic operators do not guarantee left-to-right evaluation, nor does the side effect of the `++` operator have to be applied immediately. `n++` and `arr[n]` are *unsequenced* relative to each other, and the result is not guaranteed to be consistent or predictable. The behavior is *undefined* per the language definition. – John Bode Mar 17 '21 at 13:07

3 Answers3

1

This code is invalid (reason) so you should bin it.

It is better to write more lines to keep the code readable and correct than to write "hacky" complex expressions.

val = n + arr[n];
n++;
0___________
  • 60,014
  • 4
  • 34
  • 74
1

It's not a matter of readability. That's undefined behavior.
In C + is not a sequence point, therefore you can't know if n++ will be executed before or after arr[n]

Sequence points in the C standard
See the section relative to Program execution

The presence of a sequence point between the evaluation of expressions A and B implies that every value computation and side effect associated with A is sequenced before every value computation and side effect associated with B. (A summary of the sequence points is given in annex C.)

Jack Lilhammers
  • 1,207
  • 7
  • 19
  • @0___________ done. It's not the best answer, but now it's only about **C** – Jack Lilhammers Mar 17 '21 at 16:35
  • @EricPostpischil done. It's not the best answer, but now it's only about C – Jack Lilhammers Mar 17 '21 at 16:35
  • Actually, this answer could be better but this is actually the best answer IMO (for now) because the two other answers propose one single alternate code to something that is undefined. Either you propose no alternate code at all like you did, or better you propose two alternate code snippets. Too bad you waited to much before fixing your answer which has now 5 downvotes. – xhienne Mar 17 '21 at 17:56
  • @xhienne I know, but I was working and I needed a little time to focus on fixing the answer :) – Jack Lilhammers Mar 17 '21 at 18:02
-2

It depend on the case, You can do like this.

val = n + arr[n + 1];
n++;
starboy_jb
  • 899
  • 1
  • 6
  • 13
  • No, you can't do it like this. Some compilers will treat this code as you have written it, others will treat it like `val = n + arr[n]; n += 1;` and others will cause demons to fly out of the user's nose. – William Pursell Mar 17 '21 at 11:08
  • 5
    @WilliamPursell There's nothing wrong with the current code in this answer. – Blastfurnace Mar 17 '21 at 11:16
  • 1
    Yes, there is. It does not necessarily do what the author of the original code expected it to do, nor does it do what the current code is actually doing. – William Pursell Mar 17 '21 at 11:18
  • 1
    @WilliamPursell It might not do what the OP wanted but there's not undefined behavior. – Blastfurnace Mar 17 '21 at 11:19
  • My comment was not intended to imply that the code given in this answer invokes undefined behavior, but that the code given in this answer does not duplicate the code that it is supposed to be rewriting. – William Pursell Mar 17 '21 at 11:21
  • 2
    @WilliamPursell I was responding to the "nasal demons" in your first comment. The code is well-formed. – Blastfurnace Mar 17 '21 at 11:22
  • 1
    @WilliamPursell the code is actually correct. It does exactly what the current code does. In an article about MISRA-C, they gave the exact same answer for this line of code. So the downvote is unnecessary. – Abdel Aleem Mar 17 '21 at 13:46
  • @startboy_b great job – Abdel Aleem Mar 17 '21 at 13:47
  • @AbdelAleem: The behavior of “val = n++ + arr[n];” is not defined by the C standard due to the rule in C 2018 6.5 2. If you read “an article” that said there is an “answer” for this code that it has a specific behavior in C, then it is a bad and wrong article. – Eric Postpischil Mar 17 '21 at 14:02
  • 1
    The code given in this answer absolutely does *not* do what the code in the question does. The code in the question invokes undefined behavior. This should not be the accepted answer. It is extremely disheartening to see that it has been selected. – William Pursell Mar 17 '21 at 14:08
  • 1
    At the very least, if this is to stand as the accepted answer, it *must* be edited to mention that the original code invokes undefined behavior. – William Pursell Mar 17 '21 at 14:11
  • @WilliamPursell: You can vote to delete the answer and/or the question. – Eric Postpischil Mar 17 '21 at 14:54
  • 1
    @WilliamPursell: Note that I must disagree with your statement that the code is this answer “absolutely” does not do what the code in the question does. It might. “Undefined behavior” is not a thing that is done; it is not meaningful to say that the code in the question does or performs undefined behavior. When executed, something will happen, and it could be what the code in this answer does. It would be accurate to say the code in this answer absolutely does not have the same semantics as the code in the question, meaning the specifications of what they must and may do are different. – Eric Postpischil Mar 17 '21 at 14:57