Comparison operator

Discussion in 'C Programming' started by Jean-Christophe, Jun 18, 2009.

  1. 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
    Jean-Christophe, Jun 18, 2009
    #1
    1. Advertising

  2. Jean-Christophe

    Eric Sosman Guest

    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
    lid
    Eric Sosman, Jun 18, 2009
    #2
    1. Advertising

  3. On Jun 18, 1:08 pm, pete <> 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, Jun 18, 2009
    #3
  4. On Jun 18, 1:09 pm, Eric Sosman <> 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.
    Jean-Christophe, Jun 18, 2009
    #4
  5. Jean-Christophe

    Eric Sosman Guest

    Jean-Christophe wrote:
    > On Jun 18, 1:09 pm, Eric Sosman <> 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
    lid
    Eric Sosman, Jun 18, 2009
    #5
  6. Jean-Christophe

    Richard Bos Guest

    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;


    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
    Richard Bos, Jun 18, 2009
    #6
  7. Jean-Christophe

    Walter Banks Guest

    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..
    Walter Banks, Jun 18, 2009
    #7
  8. On Jun 18, 10:37 pm, Jean-Christophe <> wrote:
    > On Jun 18, 1:08 pm, pete <> wrote:
    >
    > > It depends on what you mean by "always".

    >
    > I mean 'on any compiler'.


    Better would be 'on any conforming implementation.'

    --
    Peter
    Peter Nilsson, Jun 19, 2009
    #8
  9. Jean-Christophe

    Richard Bos Guest

    Eric Sosman <> wrote:

    > Richard Bos wrote:
    > > Jean-Christophe <> 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
    Richard Bos, Jun 23, 2009
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. jstanforth
    Replies:
    13
    Views:
    12,736
  2. Will McGugan

    case insensitive comparison operator ?

    Will McGugan, Aug 18, 2004, in forum: Python
    Replies:
    2
    Views:
    8,827
    Max M
    Aug 18, 2004
  3. Mike Duffy
    Replies:
    4
    Views:
    253
    bruno at modulix
    Jun 17, 2006
  4. Gary Herron
    Replies:
    3
    Views:
    232
    David Isaac
    Jun 19, 2006
  5. Deepu
    Replies:
    1
    Views:
    238
    ccc31807
    Feb 7, 2011
Loading...

Share This Page