Comma operator in a conditional

Question

I have read in a lot of places but I really can't understand the specified behavior in conditionals.

I understand that in assignments it evaluates the first operand, discards the result, then evaluates the second operand.

But for this code, what it supposed to do?

CPartFile* partfile = (CPartFile*)lParam;
ASSERT( partfile != NULL );
bool bDeleted = false;
if (partfile,bDeleted)
    partfile->PerformFileCompleteEnd(wParam);

The partfile in the IF was an unnecessary argument, or it have any meaning?

Answer 1

In this case, it is an unnecessary expression, and can be deleted without changing the meaning of the code.

Answer 2

The comma operator performs the expression of the first item, discards the results, then evaluates the result as the last expression.

So partfile,bDeleted would evaulate whatever partfile would, discard that result, then evaluate and return bDeleted

It's useful if you need to evaluate something which has a side-effect (for example, calling a method). In this case, though, it's useless.

For more information, see Wikipedia: Comma operator

Answer 3

bool bDeleted = false;
if (partfile,bDeleted)
    partfile->PerformFileCompleteEnd(wParam);

Here, the if statement evaluates partfile,bDeleted, but bDelete is always false, so the expression fails to run. The key question is "what's that all about?". The probable answer is that someone temporarily wanted to prevent the partfile->PerformFileCompleteEnd(wParam); statement from running, perhaps because it was causing some problem or they wanted to ensure later code reported errors properly if that step wasn't performed. So that they're remember how the code used to be, they left the old "if (partfile)" logic there, but added a hardcoded bDeleted variable to document that the partfile->Perform... logic had effectively been "deleted" from the program.

A better way to temporarily disable such code is probably...

#if 0
    if (partfile)
        partfile->PerformFileCompleteEnd(wParam);
#endif

...though sometimes I try to document the reasoning too...

#ifndef DONT_BYPASS_FILE_COMPLETE_PROCESSING_DURING_DEBUGGING
    if (partfile)
        partfile->PerformFileCompleteEnd(wParam);
#endif

...or...

if (partFile, !"FIXME remove this after debugging")
    partfile->PerformFileCompleteEnd(wParam);

The best choice depends on your tool set and existing habits (e.g. some editors highlight "FIXME" and "TODO" in reverse video so it's hard to miss or grey out #if 0 blocks; you might have particular strings your source-control checkin warns about; preprocessor defines only in debug vs release builds can prevent accidental distribution etc.).

Answer 4

partfile is evaluated, then bDeleted is evaluated and used as the test. Since evaluation of partfile does not have any side effects, removing it from the conditional has no effect.

Answer 5

The comma operator is a rather obscure feature of C/C++. It should not be confused with the comma in initialising lists (ie: int x, int y; ) nor with function call parameter separation comma (ie: func(x, y) ).

The comma operator has one single purpose: to give the programmer a guaranteed order of evaluation of an expression. For almost every operator in C/C++, the order of evaluation of expressions is undefined. If I write

result = x + y;

where x and y are subexpressions, then either x or y can be evaluated first. I cannot know which, it's up to the compiler. If you however write

result = x, y;

the order of evaluation is guaranteed by the standard: left first.

Of course, the uses of this in real world applications are quite limited...