Velocity Reviews > Comparison operator

# Comparison operator

Jean-Christophe
Guest
Posts: n/a

 06-18-2009
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
Guest
Posts: n/a

 06-18-2009
Jean-Christophe wrote:
> 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 ?

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

> 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).

--
Eric Sosman
http://www.velocityreviews.com/forums/(E-Mail Removed)lid

Jean-Christophe
Guest
Posts: n/a

 06-18-2009
On Jun 18, 1:08*pm, pete <(E-Mail Removed)> wrote:

> 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
Guest
Posts: n/a

 06-18-2009
On Jun 18, 1:09*pm, Eric Sosman <(E-Mail Removed)> wrote:

> > 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 ?

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

> > I'd like to know if the code #1 can always replace the code #2:
> > n += (x > a) - (x < a); // #1
> > if (x > a) ++n; else if (x < a) --n; // #2

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

Okay, thanks.

Eric Sosman
Guest
Posts: n/a

 06-18-2009
Jean-Christophe wrote:
> On Jun 18, 1:09 pm, Eric Sosman <(E-Mail Removed)> wrote:
>
>>> 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 ?

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

>
>>> I'd like to know if the code #1 can always replace the code #2:
>>> n += (x > a) - (x < a); // #1
>>> if (x > a) ++n; else if (x < a) --n; // #2

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

>
> 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.

--
Eric Sosman
(E-Mail Removed)lid

Richard Bos
Guest
Posts: n/a

 06-18-2009
Jean-Christophe <(E-Mail Removed)> wrote:

> 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
Guest
Posts: n/a

 06-18-2009

pete wrote:

> Jean-Christophe wrote:
> > 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

>
> 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
Guest
Posts: n/a

 06-19-2009
On Jun 18, 10:37*pm, Jean-Christophe <(E-Mail Removed)> wrote:
> On Jun 18, 1:08*pm, pete <(E-Mail Removed)> wrote:
>
> > It depends on what you mean by "always".

>
> I mean 'on any compiler'.

Better would be 'on any conforming implementation.'

--
Peter

Richard Bos
Guest
Posts: n/a

 06-23-2009
Eric Sosman <(E-Mail Removed)> wrote:

> Richard Bos wrote:
> > Jean-Christophe <(E-Mail Removed)> wrote:
> >
> >> 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.

>
> 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