Comparison operator

[Jean-Christophe]

Can I assume that an expression like ( X comparison_operator Y )
is always evaluated 0 when it's false and 1 when it's true,
independantly of the compiler used ?

I'd like to know if the code #1 can always replace the code #2:

// #1
n += (x > a) - (x < a);

// #2
if (x > a)
++n;
else if (x < a)
--n;

TIA

 

[Eric Sosman]

Can I assume that an expression like ( X comparison_operator Y )
is always evaluated 0 when it's false and 1 when it's true,
independantly of the compiler used ?

I'd like to know if the code #1 can always replace the code #2:

// #1
n += (x > a) - (x < a);

// #2
if (x > a)
++n;
else if (x < a)
--n;

Yes (assuming n, a, x are valid to begin with).

 

[Jean-Christophe]

It depends on what you mean by "always".

I mean 'on any compiler'.

If (x) is a macro for an expression with side effects,
then #1 and #2 are not the same, since the side effects
will occur twice in #1, but only once for #2.

No macro is involved here: 'n' is an integer,
'x' and 'a' are numeric variables of the same format.

 

[Jean-Christophe]

 Yes.  All of ==, !=, <, <=, >, and >= behave this way.
So does !, the logical negation operator.

 Yes (assuming n, a, x are valid to begin with).

Okay, thanks.

 

[Eric Sosman]

Okay, thanks.

Actually, I'd overlooked side-effects; see pete's response.
If `x' or `a' has side-effects, #1 might even have undefined
behavior (consider `#define x ++z', for example).

But if `x' and `a' are "ordinary values," the forms
are equivalent.

 

[Richard Bos]

Can I assume that an expression like ( X comparison_operator Y )
is always evaluated 0 when it's false and 1 when it's true,
independantly of the compiler used ?

I'd like to know if the code #1 can always replace the code #2:

// #1
n += (x > a) - (x < a);

// #2
if (x > a)
++n;
else if (x < a)
--n;

Can, yes. Should is another matter. #2 is more legible. If strapped for
space, you could write it on one line like this:

if (x > a) ++n; else if (x < a) --n;

and still be more maintainable than #1.

Richard

 

[Walter Banks]

It depends on what you mean by "always".

If (x) is a macro for an expression with side effects,
then #1 and #2 are not the same, since the side effects
will occur twice in #1, but only once for #2.

#define x (puts("x"))

Side effects could be once or twice in #2.

w..

 

[Peter Nilsson]

I mean 'on any compiler'.

Better would be 'on any conforming implementation.'

 

[Richard Bos]

Eye of the beholder, I guess.

True, of course.

I frequently use something
very like #1 in comparison functions for qsort() when the
type and/or range isn't suitable for a simple subtraction:

Yehess... so do I. But that is a special occasion. I would not
unreservedly use such constructs in normal code. In qsort() comparison
functions, though, I'll readily use both this and casts.

Richard