1. Forum
  2. Usenet
  3. COMP.LANG.C

  • Shortcut Booleans

    From Lawrence D'Oliveiro@21:1/5 to All on Fri Jun 7 10:52:51 2024
    I wonder why, traditionally, shortcut evaluation of boolean subexpressions
    has been applied to “and” and “or” connectives, but not any others.

    For example, what about “implies”?

    a implies b

    Truth table:

    a b result
    ------------
    0 0 1
    0 1 1
    1 0 0
    1 1 1

    But C does not have an “implies” operator, I hear you say? Of course this can be written

    not a or b

    and shortcut evaluation would apply. But it can also be written

    a <= b

    and shortcut evaluation would *not* apply. Why not, if a and b are boolean-valued subexpressions?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From bart@21:1/5 to Lawrence D'Oliveiro on Fri Jun 7 13:41:06 2024
    On 07/06/2024 11:52, Lawrence D'Oliveiro wrote:
    I wonder why, traditionally, shortcut evaluation of boolean subexpressions has been applied to “and” and “or” connectives, but not any others.

    Common sense applies, otherwise you could shortcut these operations:

    a * b // when a is zero, the result is zero
    a & b // when a is zero

    Here you would probably spend more time checking the value of 'a' then branching, than just doing the operation.

    The language chooses to specify that both operands are always evaluated.
    That is the most useful behaviour.

    Short-circuiting logical ops are mainly associated with conditional
    expressions used for branching, such as in 'if', 'while', 'for' statements.

    If both operands always had to be evaluated, then code would be
    inefficient as it would need to create an actual result:

    if (f() && g())

    Not only would both functions be called, but you'd need to combine the
    results which means remembering the value of f().


    (I have played with a logical and/or operators that didn't have
    short-circuit semantics; they worked like this:

    if f() andb g()

    ('andb' means 'and-both'.) But I already had too many such features and eventually it was dropped.

    My 'andb' example be trivially expressed in other ways, such as in this C:

    if (!!f() & !!g())

    )


    For example, what about “implies”?

    a implies b

    What about it? I've never used that, ever. I doubt many have.

    If it can be rewritten 'not a or b' then just use that.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to bart on Sat Jun 8 02:42:15 2024
    On Fri, 7 Jun 2024 13:41:06 +0100, bart wrote:

    Common sense applies, otherwise you could shortcut these operations:

    a * b // when a is zero, the result is zero
    a & b // when a is zero

    And why not? It would depend on the complexity of the “a” and “b” subexpressions, of course.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From David Brown@21:1/5 to Lawrence D'Oliveiro on Sun Jun 9 13:35:12 2024
    On 08/06/2024 04:42, Lawrence D'Oliveiro wrote:
    On Fri, 7 Jun 2024 13:41:06 +0100, bart wrote:

    Common sense applies, otherwise you could shortcut these operations:

    a * b // when a is zero, the result is zero
    a & b // when a is zero

    And why not? It would depend on the complexity of the “a” and “b” subexpressions, of course.

    The language defines "shortcutting" for operators so that you know
    whether "a" and "b" will both be evaluated, or just one of them.
    Understanding these is vital to making your code correct.

    Whether the implementation /actually/ evaluates "a" and "b", and in what
    order, is a matter of implementation efficiency - as long as it
    generates results that have the correct observable behaviour.

    In general, it would be inconvenient if you did not know whether "a @ b"
    was going to evaluate "b", including all function calls and side-effects.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Lawrence D'Oliveiro@21:1/5 to David Brown on Mon Jun 10 01:51:30 2024
    On Sun, 9 Jun 2024 13:35:12 +0200, David Brown wrote:

    In general, it would be inconvenient if you did not know whether "a @ b"
    was going to evaluate "b", including all function calls and
    side-effects.

    Ada has “and then” and “or else”, so that you can specifically request shortcut evaluation when program correctness depends on it, and leave it
    up to the implementation otherwise.

    This principle could be extended to other situations ...

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)