easy c question regarding post increment and break from loop

[snarkysparky]

This line is in a loop

if (CMDPrefixFirstLocations[CntrlPrefixIndex++] <= CharLp) break;

If the break is executed is the last  CntrlPrefixIndex++   done before the break.

In other words will the loop exit with CntrlPrefixIndex at the index that caused the break or will it be 1 more than that.

Thanks  C   experts

[Ian.M]

The post-increment is applied after evaluating the expression for the if condition *BEFORE* executing the block controlled by the if statement.
 If you don't want the increment to happen on the last pass, you need to move it out of the condition and into a new else block.

[Mechatrommer]

compare CMDPrefixFirstLocations[CntrlPrefixIndex] first, and then increment CntrlPrefixIndex, and then break based on compare condition made earlier.

[TheCalligrapher]

This line is in a loop

if (CMDPrefixFirstLocations[CntrlPrefixIndex++] <= CharLp) break;

If the break is executed is the last  CntrlPrefixIndex++   done before the break.

Yes, it is. `CntrlPrefixIndex++` is evaluated before the `break`. That means the increment is always done.

The post-increment is applied after evaluating the expression for the if condition *BEFORE* executing the block controlled by the if statement.

"after evaluating the expression for the if condition"? No, you can't make claims like that. No one knows when post-increment is physically applied within this expression. And it doesn't really matter. The only thing that matters is that the subscripting is guaranteed to use the original ("old", "before increment") value of `CntrlPrefixIndex`.

[SiliconWizard]

The post-increment is applied after evaluating the expression for the if condition *BEFORE* executing the block controlled by the if statement.
 If you don't want the increment to happen on the last pass, you need to move it out of the condition and into a new else block.

Yes. And while this is perfectly valid C (if that was what was intended), I personally recommend avoiding using pre/post-incrementation/decrementation combined with accessing the value.
It tends to make your code a bit harder to read (even if you are a very seasoned C programmer, it will always take a couple seconds more to figure out and there's no good rationale for that IMHO) and is a nice source of potential bugs just like with the example code you provided.

Generally speaking, avoid expressions that can do several things at the same time. But of course that is just advice and I'm sure you'll find a lot of contradicting advice about that out there.

[DavidAlfa]

Code: [Select]

if (CMDPrefixFirstLocations[CntrlPrefixIndex++] <= CharLp) break;
                                              ^             
                                              Increased here, before taking any action

If you want to avoid that:

Code: [Select]

if (CMDPrefixFirstLocations[CntrlPrefixIndex] <= CharLp) break;
CntrlPrefixIndex++;                                                    // This won't happen if it did the break


[newbrain]

after evaluating the expression for the if condition"? No, you can't make claims like that. No one knows when post-increment is physically applied within this expression. And it doesn't really matter. The only thing that matters is that the subscripting is guaranteed to use the original ("old", "before increment") value of `CntrlPrefixIndex`.

Exactly so.
The only guarantee we have is that the side effects are complete at each sequence point, but there are  no requirements on the side effects ordering and place while evaluating each full expression.
Post increment is a side effect, and there is a sequence point between the end of the if control (full) expression and a following full expression.
(C11, Annex 3 - sequence points).

The post-increment is applied after evaluating the expression for the if condition *BEFORE* executing the block controlled by the if statement.
 If you don't want the increment to happen on the last pass, you need to move it out of the condition and into a new else block.

Forgetting the "after evaluating" that's been already discussed, and spraining my nitpick ligament  , I would object that the standard does not really force the side effect to complete before the break is executed.
Sequence points are only defined in terms of evaluations and break is not an expression, albeit it's guaranteed that there'll be a SP before the result of the side effect (++) can be used in any way.
A smart compiler might notice that all program paths will somehow yield an incremented CntrlPrefixIndex and place its actual increment in a more optimal position.

[Mechatrommer]

The post-increment is applied after evaluating the expression for the if condition *BEFORE* executing the block controlled by the if statement.
 If you don't want the increment to happen on the last pass, you need to move it out of the condition and into a new else block.

Yes. And while this is perfectly valid C (if that was what was intended), I personally recommend avoiding using pre/post-incrementation/decrementation combined with accessing the value.
It tends to make your code a bit harder to read (even if you are a very seasoned C programmer, it will always take a couple seconds more to figure out and there's no good rationale for that IMHO) and is a nice source of potential bugs just like with the example code you provided.

Generally speaking, avoid expressions that can do several things at the same time. But of course that is just advice and I'm sure you'll find a lot of contradicting advice about that out there.

this is a conflict (or a compromise) issue... that "feature" is for shortcut to reduce number of code lines and fatigue hand (pro) but can be harder to read/comprehend (con) if not well versed in the language, try to be traditious as you've suggested can be easier to read and avoid bug risk (pro) but requires more line of codes (con), so i say both techniques are rational to use... imho one can freely choose...

Code: [Select]

if (a[b++] < c) break;

or..

Code: [Select]

if (a[b] < c) {
  b++;
  break;
} else {
  b++;
}

are semantically the same.

[newbrain]

are semantically the same.

Nope.
Or at least, you can't say without seeing what's inside function a().
There is a sequence point before the effective function call, at the end of the arguments evaluation.

So:

Code: [Select]

int b;

int a(int x) { return x + b; }
Might execute different branches in the two versions.

[TheCalligrapher]

Code: [Select]

if (a(b++) < c) break;

or..

Code: [Select]

if (a(b) < c) {
  b++;
  break;
} else {
  b++;
}

are semantically the same.

Your second version suffers from violation of DRY ("Don't Repeat Yourself") principle. A typical alternative would normally look as

Code: [Select]

x = b;
++b;
if (a(x) < c)
  break;

or as

Code: [Select]

bool is_done = a(b) < c;
++b;
if (is_done)
  break;
(assuming that there are no issues mentioned by newbrain above)

[Mechatrommer]

are semantically the same.

Nope.

sorry that was a serious typo (semantic error) i meant array element like in OP (as i am also program in VB which use () as array indexing) typo corrected. but i think even if its meant a function call, your function example will give same result on both of the code variant. but that besides the point. ymmv.

Code: [Select]

x = b;
++b;
if (a(x) < c)
  break;

or as

Code: [Select]

bool is_done = a(b) < c;
++b;
if (is_done)
  break;

those suffer WTRV (whats that redundant variable?) and TCTR (too cryptic to read)

[TheCalligrapher]

those suffer WTRV (whats that redundant variable?) and TCTR (too cryptic to read)

Well, one cure to WTRV problem is the original version suffering from DTMTAO ("doing too many things at once") syndrome (which is a strain of TCTR), so we are back to square one: it is either WTRV or DRY or DTMTAO/TCTR. Choose your poison.

However, both WTRV and TCTR is easily alleviated by NYVD ("name your variables descriptively") techinque. So, while my `x` might be suffering from a case of WTRV, my `is_done` is completely imprevious to it.

[newbrain]

I think even if its meant a function call, your function example will give same result on both of the code variant. but that besides the point.

No, they won't (in general).
Try with b=0 and c=1.
Partly beside the point with your update.
Only partly as the point is, in fact, sequence points.