short-circuit operators - part of the spec?

Discussion in 'Java' started by Phil..., Oct 22, 2003.

  1. Phil...

    Phil... Guest

    My book says the following about && and ||
    (see below dashed line.) And I wonder if this
    is built into the language or an artifact of the
    compiler. Previously (in my youth) we were
    taught that depending on the compiler to skip
    evaluating stuff was dangerous and bad for
    maintenance.
    ----------------------------
    known as the short-circuit logical operators:
    && short-circuit AND
    || short-circuit OR
    The short-circuit feature of the && operator is that it doesn't waste its
    time on
    pointless evaluations. A short-circuit && evaluates the left side of the
    operation first
    (operand one), and if operand one resolves to false, the && operator doesn't
    bother
    looking at the right side of the equation (operand two). The operator
    already knows
    that the complete expression can't possibly be true, since one operand has
    already
    proven to be false.
    Phil..., Oct 22, 2003
    #1
    1. Advertising

  2. "Phil..." <> writes:
    > My book says the following about && and ||
    > (see below dashed line.) And I wonder if this
    > is built into the language or an artifact of the
    > compiler.


    http://java.sun.com/docs/books/jls/

    /Thomas
    Thomas Weidenfeller, Oct 22, 2003
    #2
    1. Advertising

  3. Phil... wrote:
    > My book says the following about && and ||
    > (see below dashed line.) And I wonder if this
    > is built into the language or an artifact of the
    > compiler. Previously (in my youth) we were
    > taught that depending on the compiler to skip
    > evaluating stuff was dangerous and bad for
    > maintenance.


    It's part of the language specification, and there are alternative non-short-circuit
    operators (& and |).

    BTW, the Java Language Specification is freely available and relatively easy to read:
    http://java.sun.com/docs/books/jls/second_edition/html/j.title.doc.html
    Michael Borgwardt, Oct 22, 2003
    #3
  4. Phil... wrote:

    > My book says the following about && and ||
    > (see below dashed line.) And I wonder if this
    > is built into the language or an artifact of the
    > compiler. Previously (in my youth) we were
    > taught that depending on the compiler to skip
    > evaluating stuff was dangerous and bad for
    > maintenance.
    > ----------------------------
    > known as the short-circuit logical operators:
    > && short-circuit AND
    > || short-circuit OR
    > The short-circuit feature of the && operator is that it doesn't waste its
    > time on
    > pointless evaluations. A short-circuit && evaluates the left side of the
    > operation first
    > (operand one), and if operand one resolves to false, the && operator doesn't
    > bother
    > looking at the right side of the equation (operand two). The operator
    > already knows
    > that the complete expression can't possibly be true, since one operand has
    > already
    > proven to be false.
    >
    >


    Absolutely part of the spec. That's why you can depend on them. Also
    part of the spec, hence dependable, is the left to right order of
    evaluation so you can have constructs like

    if (ref != null && ref.equals(other))
    doStuff

    With C compilers, you have no such specification, hence no ushc dependablity
    David Zimmerman, Oct 22, 2003
    #4
  5. Michael Borgwardt <> coughed up the following:

    > Phil... wrote:
    >> My book says the following about && and ||
    >> (see below dashed line.) And I wonder if this
    >> is built into the language or an artifact of the
    >> compiler. Previously (in my youth) we were
    >> taught that depending on the compiler to skip
    >> evaluating stuff was dangerous and bad for
    >> maintenance.

    >
    > It's part of the language specification, and there are alternative
    > non-short-circuit operators (& and |).
    >
    > BTW, the Java Language Specification is freely available and
    > relatively easy to read:
    > http://java.sun.com/docs/books/jls/second_edition/html/j.title.doc.html


    Freely available yes. Easy to read, no.
    Thomas G. Marshall, Oct 22, 2003
    #5
  6. David Zimmerman <> coughed up the following:

    > Phil... wrote:
    >
    >> My book says the following about && and ||
    >> (see below dashed line.) And I wonder if this
    >> is built into the language or an artifact of the
    >> compiler. Previously (in my youth) we were
    >> taught that depending on the compiler to skip
    >> evaluating stuff was dangerous and bad for
    >> maintenance.
    >> ----------------------------
    >> known as the short-circuit logical operators:
    >> && short-circuit AND
    >>>> short-circuit OR

    >> The short-circuit feature of the && operator is that it doesn't
    >> waste its time on
    >> pointless evaluations. A short-circuit && evaluates the left side of
    >> the operation first
    >> (operand one), and if operand one resolves to false, the && operator
    >> doesn't bother
    >> looking at the right side of the equation (operand two). The operator
    >> already knows
    >> that the complete expression can't possibly be true, since one
    >> operand has already
    >> proven to be false.
    >>
    >>

    >
    > Absolutely part of the spec. That's why you can depend on them. Also
    > part of the spec, hence dependable, is the left to right order of
    > evaluation so you can have constructs like
    >
    > if (ref != null && ref.equals(other))
    > doStuff
    >
    > With C compilers, you have no such specification...


    I disagree. The "spec" that you are talking about /does/ exist, and is
    guided (in the last decade or so) by ANSI. And it /does/ specify that

    if ((ptr != 0) && (*ptr == 5)) {...}

    is aborted midway if ptr is 0.
    Thomas G. Marshall, Oct 22, 2003
    #6
  7. Phil...

    Jon Skeet Guest

    Thomas G. Marshall
    <> wrote:
    > > BTW, the Java Language Specification is freely available and
    > > relatively easy to read:
    > > http://java.sun.com/docs/books/jls/second_edition/html/j.title.doc.html

    >
    > Freely available yes. Easy to read, no.


    Significantly easier than most specifications that I've seen though,
    I'd say.

    In this particular case I can't see how it could have been much easier:

    From table of contents, look for && and follow the first link (section
    15.23). From there, the first sentence is:

    <quote>
    The && operator is like & (§15.22.2), but evaluates its right-hand
    operand only if the value of its left-hand operand is true.
    </quote>

    Very simple

    --
    Jon Skeet - <>
    http://www.pobox.com/~skeet
    If replying to the group, please do not mail me too
    Jon Skeet, Oct 22, 2003
    #7
  8. Phil...

    Roedy Green Guest

    On Wed, 22 Oct 2003 16:05:01 GMT, "Phil..." <> wrote or
    quoted :

    >My book says the following about && and ||
    >(see below dashed line.)


    This short circuit behaviour is guaranteed. It lets you say things
    like

    if ( x != null && x.canDoIt() )

    --
    Canadian Mind Products, Roedy Green.
    Coaching, problem solving, economical contract programming.
    See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
    Roedy Green, Oct 22, 2003
    #8
  9. Phil...

    Roedy Green Guest

    On Wed, 22 Oct 2003 16:05:01 GMT, "Phil..." <> wrote or
    quoted :

    >My book says the following about && and ||
    >(see below dashed line.)


    What does it have to say about the ? : operator? Are you guaranteed
    only one of the true/false expressions will be evaluated?

    --
    Canadian Mind Products, Roedy Green.
    Coaching, problem solving, economical contract programming.
    See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
    Roedy Green, Oct 22, 2003
    #9
  10. Jon Skeet <> coughed up the following:

    ....[tear]...

    > In this particular case I can't see how it could have been much
    > easier:
    >
    > From table of contents, look for && and follow the first link (section
    > 15.23). From there, the first sentence is:
    >
    > <quote>
    > The && operator is like & (§15.22.2), but evaluates its right-hand
    > operand only if the value of its left-hand operand is true.
    > </quote>
    >
    > Very simple


    Oh in this case I certainly agree. But the JLS is filled with hard to read
    mumble, IMHO, and that has nothing to do with whether or not /other/
    specifications are also hard to read (they are).

    And there might not be any other way to write it. Language specs are, after
    all, /meant/ to be hairy I think.

    But take for example this bit of gobledgook in 15.25 (the "?" operator):

    ---------------[START]-------------
    The type of a conditional expression is determined as follows:


    a.. If the second and third operands have the same type (which may be the
    null type), then that is the type of the conditional expression.
    b.. Otherwise, if the second and third operands have numeric type, then
    there are several cases:
    a.. If one of the operands is of type byte and the other is of type
    short, then the type of the conditional expression is short.
    b.. If one of the operands is of type T where T is byte, short, or char,
    and the other operand is a constant expression of type int whose value is
    representable in type T, then the type of the conditional expression is T.
    c.. Otherwise, binary numeric promotion (§5.6.2) is applied to the
    operand types, and the type of the conditional expression is the promoted
    type of the second and third operands. Note that binary numeric promotion
    performs value set conversion (§5.1.8).
    c.. If one of the second and third operands is of the null type and the
    type of the other is a reference type, then the type of the conditional
    expression is that reference type.
    d.. If the second and third operands are of different reference types,
    then it must be possible to convert one of the types to the other type (call
    this latter type T) by assignment conversion (§5.2); the type of the
    conditional expression is T. It is a compile-time error if neither type is
    assignment compatible with the other type.
    ---------------[END]-------------

    I read that and want to respond with "eughhhh".

    And then, recently, I bumped into this hoo haa in 5.1.3 (Narrowing Primitive
    Conversions):

    ---------------[START]-------------
    A narrowing conversion of a floating-point number to an integral type T
    takes two steps:

    1.. In the first step, the floating-point number is converted either to a
    long, if T is long, or to an int, if T is byte, short, char, or int, as
    follows:
    a.. If the floating-point number is NaN (§4.2.3), the result of the
    first step of the conversion is an int or long 0.
    b.. Otherwise, if the floating-point number is not an infinity, the
    floating-point value is rounded to an integer value V, rounding toward zero
    using IEEE 754 round-toward-zero mode (§4.2.3). Then there are two cases:
    a.. If T is long, and this integer value can be represented as a long,
    then the result of the first step is the long value V.
    b.. Otherwise, if this integer value can be represented as an int,
    then the result of the first step is the int value V.
    c.. Otherwise, one of the following two cases must be true:
    a.. The value must be too small (a negative value of large magnitude
    or negative infinity), and the result of the first step is the smallest
    representable value of type int or long.
    b.. The value must be too large (a positive value of large magnitude
    or positive infinity), and the result of the first step is the largest
    representable value of type int or long.
    2.. In the second step:
    a.. If T is int or long, the result of the conversion is the result of
    the first step.
    b.. If T is byte, char, or short, the result of the conversion is the
    result of a narrowing conversion to type T (§5.1.3) of the result of the
    first step.
    ---------------[END]-------------
    Thomas G. Marshall, Oct 22, 2003
    #10
  11. Roedy Green <> scribbled the following:
    > On Wed, 22 Oct 2003 16:05:01 GMT, "Phil..." <> wrote or
    > quoted :
    >>My book says the following about && and ||
    >>(see below dashed line.)


    > What does it have to say about the ? : operator? Are you guaranteed
    > only one of the true/false expressions will be evaluated?


    AFAIK that is indeed guaranteed. Also the condition is guaranteed to
    execute before either the true or the false expression.

    --
    /-- Joona Palaste () ------------- Finland --------\
    \-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
    "The truth is out there, man! Way out there!"
    - Professor Ashfield
    Joona I Palaste, Oct 23, 2003
    #11
    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. Phil...
    Replies:
    1
    Views:
    974
    Thomas G. Marshall
    Oct 22, 2003
  2. JS#
    Replies:
    5
    Views:
    3,532
    Roedy Green
    Nov 21, 2005
  3. Stefanie Ertheld

    short circuit operators

    Stefanie Ertheld, Feb 24, 2008, in forum: Java
    Replies:
    26
    Views:
    1,697
  4. Anthony Paul

    short-circuit evaluation and assignment operators

    Anthony Paul, Jun 6, 2009, in forum: C Programming
    Replies:
    5
    Views:
    1,290
  5. Andrew Chen
    Replies:
    1
    Views:
    195
    David Chelimsky
    Mar 25, 2008
Loading...

Share This Page