short-circuit operators - part of the spec?

Posted: 2003-10-23 0:05:00

java-programmer, short-circuit operators - part of the spec? 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.

Posted: 2003-10-23 0:10:00

java-programmer >> short-circuit operators - part of the spec? 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.

Posted: 2003-10-23 0:10:00

java-programmer >> short-circuit operators - part of the spec? "Phil..." <email***@***.com> 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

Posted: 2003-10-23 0:19:00

java-programmer >> short-circuit operators - part of the spec? 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

Posted: 2003-10-23 0:25:00

java-programmer >> short-circuit operators - part of the spec? 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

Posted: 2003-10-23 0:41:00

java-programmer >> short-circuit operators - part of the spec? Michael Borgwardt <email***@***.com> 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.

Posted: 2003-10-23 0:44:00

java-programmer >> short-circuit operators - part of the spec? Phil... <email***@***.com> coughed up the following:

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

Depends upon the language, and no, there is nothing wrong with it when it is
specifically allowed.

In your youth, if you used C or C++, you have the same "short circuit"
evaluation leap that you have in java.

What /is/ a bad idea, which is probably what you're confusing this with, is
to rely upon a feature that happens to be present in a compiler but isn't
specified in the language spec. That /is/ dangerous.

Posted: 2003-10-23 0:47:00

java-programmer >> short-circuit operators - part of the spec? David Zimmerman <email***@***.com> 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.

Posted: 2003-10-23 1:39:00

java-programmer >> short-circuit operators - part of the spec? Thomas G. Marshall
<email***@***.com> 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 & (?5.22.2), but evaluates its right-hand
operand only if the value of its left-hand operand is true.
</quote>

Very simple

--
Jon Skeet - <email***@***.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

Posted: 2003-10-23 5:57:00

java-programmer >> short-circuit operators - part of the spec? Jon Skeet <email***@***.com> 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 & (?5.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 (?.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 (?.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 (?.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 (?.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 (?.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 (?.1.3) of the result of the
first step.
---------------[END]-------------

Posted: 2003-10-24 4:42:00

java-programmer >> short-circuit operators - part of the spec? Roedy Green <email***@***.com> scribbled the following:
> On Wed, 22 Oct 2003 16:05:01 GMT, "Phil..." <email***@***.com> 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 (email***@***.com) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"The truth is out there, man! Way out there!"
- Professor Ashfield