+= and =

[asit]

In java

lets consider the following code
byte b = 0;
byte a =10;
b += a;
it shows no error.

But in the following code

byte b = 0;
byte a =10;
b = b+ a;
it shows possible loss of precision.
found : int
required : bye

Though both these code apparently do the some things, why it gives
error in 2nd case ???

 

[Michael Rauscher]

In java

lets consider the following code
byte b = 0;
byte a =10;
b += a;
it shows no error.

But in the following code

byte b = 0;
byte a =10;
b = b+ a;
it shows possible loss of precision.
found : int
required : bye

Though both these code apparently do the some things, why it gives
error in 2nd case ???

They don't do the same things. The first example uses the compund
assignment operator '+='.

The JLS states in section 15.26.2 [1]:

A compound assignment expression of the form E1 op= E2 is equivalent to
E1 = (T)((E1) op (E2)), where T is the type of E1, except that E1 is
evaluated only once.

Therefore, you'd have to write b = (byte)(b + a) to have your second
example do the same thing as your first example.

OTOH, '+' is an additive operator [2] which causes byte operands to be
converted to int [3].

Bye
Michael

[1]
<http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#15.26.2>
[2]
<http://java.sun.com/docs/books/jls/third_edition/html/expressions.html#15.18.2>
[3]
<http://java.sun.com/docs/books/jls/third_edition/html/conversions.html#5.6.2>

 

[blue indigo]

They don't do the same things.

Which is counterintuitive; people expect b += a to be equivalent to b = b
+ a unless b is an expression with side-effects. (This sort of gotcha
mostly doesn't happen in C, and only in C++ if someone has been badly
abusing operator overloading.)

That this expectation is violated by Java is a bit of a wart. But Java has
a few of those.

 

[Lew]

Which is counterintuitive; people expect b += a to be equivalent to b = b
+ a unless b is an expression with side-effects. (

They don't if they are familiar with Java.

That this expectation is violated by Java is a bit of a wart. But Java has
a few of those.

What you affect to call a "wart" is Java making life easier by including the
cast as part of the semantics of the operator. How else would you deal with
the narrowing conversion and still support the simplicity of the operator, hm?

It is the height of irresponsibility to use an operator in a programming
language without understanding its effects. It is foolish to judge Java's
semantics on the basis of another language's. Just look at the difference
between C++'s "reference" and Java's for another example.

The whole point of the (op)= operators is convenience; it supports that
convenience to include both the (op) and the (cast) in the semantics. The
semantics are logical and well-documented. It is stupid to whine that they
should be different, at least unless you have a better alternative.

 

[Lew]

Which is counterintuitive; people expect b += a to be equivalent to b = b
+ a unless b is an expression with side-effects.

So you expect:

byte a, b;
b = 0;
a = 1;
b += a;

to cause a compiler warning?

 

[Arne Vajh¸j]

Which is counterintuitive; people expect b += a to be equivalent to b = b
+ a unless b is an expression with side-effects. (This sort of gotcha
mostly doesn't happen in C, and only in C++ if someone has been badly
abusing operator overloading.)

The problem does not exist in C because C does not complain
when assigning a wide integer to a narrow integer.

But Java checks for that.

The += would be useless in Java for byte and short
if it did not do that cast automatically.

Arne

 

[Arne Vajh¸j]

Arne Vajh¸j wrote:
...
...

However, the problem is itself a consequence of another issue, the
decision to convert byte to int for arithmetic. Back when Java was
designed, it could have been defined to do byte arithmetic, so that the
type of a+b, for bytes a and b, would itself be byte.

Casts could be used if two bytes needed to be added in int, just as one
writes (double)a/b to force a double division of two integers.

Very true.

If I were to guess then I would guess that decision was made
to make:

byte a = 100;
byte b = 100;
System.out.println(a + b);

actually write 200.

Arne

 

[Roedy Green]

Which is counterintuitive; people expect b += a to be equivalent to b = b
+ a unless b is an expression with side-effects. (This sort of gotcha
mostly doesn't happen in C, and only in C++ if someone has been badly
abusing operator overloading.)

The += operator includes a built in cast. If it did not have that
feature there is no place you could put the cast manually. So it HAS
to be built in.

The "wart" if any is

b1 = b2 + b3;
not doing what you might expect where all three are byte. This comes
from Java being designed as an afterthought to the JVM which has only
int operators, no byte ones.

--
Roedy Green Canadian Mind Products
http://mindprod.com

"Learning is not compulsory... neither is survival."
~ Dr. W. (William) Edwards Deming (born: 1900-10-14 died: 1993-12-20 at age: 93))

 

[Roedy Green]

Isn't it simply to imitate C ?

that sounds plausible. Java has the case fall through design flaw just
like C. It has the goofy half prefix half postfix notation and very
complex precedence, like C.

Gosling was very much a bottom up thinker. He designed the JVM as an
elegantly simple virtual machine that gave the implementor
extraordinary flexibility. Java was a sort of high level assembler
for it, much like C was a high level assembler for the PDP 11.
--
Roedy Green Canadian Mind Products
http://mindprod.com

"Learning is not compulsory... neither is survival."
~ Dr. W. (William) Edwards Deming (born: 1900-10-14 died: 1993-12-20 at age: 93))

 

[Wojtek]

Roedy Green wrote :

Java has the case fall through design flaw just
like C.

Flaw?

switch(val)
{
case 1:
doSomething();
break;

case 2:
default:
doThis();
break;
}

 

[Roedy Green]

Flaw?

switch(val)
{
case 1:
doSomething();
break;

case 2:
default:
doThis();
break;

leaving out the break is not an error.
--
Roedy Green Canadian Mind Products
http://mindprod.com

"Learning is not compulsory... neither is survival."
~ Dr. W. (William) Edwards Deming (born: 1900-10-14 died: 1993-12-20 at age: 93))

 

[Lew]

Roedy Green wrote :

Flaw?

switch(val)
{
case 1:
doSomething();
break;

case 2:
default:
doThis();
break;
}

There is a tendency, at least among Java enthusiasts, to label design features
of the language "flaws" and justify the judgment with a corner case where
extra work is needed to prevent a problem due to use of the feature.

Providing a use case where the putative "flaw" provides an advantage never
seems to convince these naysayers that the feature is not a flaw.

I prefer this jaundiced and critical attitude amongst adherents to the blind
religious devotion sometimes evinced by followers of other programming
languages. There is not much value in casting perls among swine. Healthy
debate over the merits and disadvantages of language features, combined with
the robust JCP that permits some of this debate to actually influence the
language's development, could well keep Java viable and me employed for a
long, long time to come.

 

[Lew]

leaving out the break is not an error.

Nor is it a "flaw".

 

[Mark Space]

byte a = 100;
byte b = 100;
System.out.println(a + b);

actually write 200.

The sensible thing to do here is to throw an overflow exception, imo.
(If we're talking about bytes anyway, I don't have an issue with the
implicit conversion to int.)

 

[Arne Vajhøj]

Roedy Green wrote :

Flaw?

switch(val)
{
case 1:
doSomething();
break;

case 2:
default:
doThis();
break;
}

Yes.

It allows programmers to save a bit of typing by reusing code
via fall through at the expensive of producing no compile time
error and weird runtime errors if the programmer forget a break.

That is a bad deal.

It is very unlikely that it will ever be changed. It would
break existing code.

But it should have been designed different 15 years ago to
match the true Java spirit.

Arne

 

[Arne Vajhøj]

There is a tendency, at least among Java enthusiasts, to label design
features of the language "flaws" and justify the judgment with a corner
case where extra work is needed to prevent a problem due to use of the
feature.

Providing a use case where the putative "flaw" provides an advantage
never seems to convince these naysayers that the feature is not a flaw.

The feature of saving lines of code at the expense of making
programming errors runtime errors instead of compile tile errors
is neither in the Java spirit or an advantage in my opinion.

Too late to change now. But if we could go back 15 years in time, then
that is one of the things they should do different.

Arne

 

[Arne Vajh¸j]

The sensible thing to do here is to throw an overflow exception, imo.
(If we're talking about bytes anyway, I don't have an issue with the
implicit conversion to int.)

That is a third solution.

But I don't think that would be popular either.

Arne

 

[Joshua Cranmer]

There is a tendency, at least among Java enthusiasts, to label design
features of the language "flaws" and justify the judgment with a corner
case where extra work is needed to prevent a problem due to use of the
feature.

There is also a tendency among enthusiasts of some languages to denote
the lack of feature XYZ a flaw in other languages. Indeed, there is
often a tendency to view anything that an entity (be it a language,
project, or even social group) has that you don't want, or what it
doesn't have that you want, as a major flaw.

The more distressing problem I notice is that most proponents of
would-be features don't seem to fully justify why they want features.
One person's pet feature is another person's arch-example of bloat.

I prefer this jaundiced and critical attitude amongst adherents to the
blind religious devotion sometimes evinced by followers of other
programming languages.

The best defenders of an entity are those who can start by saying "it's
not perfect, but..."

> There is not much value in casting perls among swine.

Was the misspelling intentional?

 

[Lew]

That is a third solution.

But I don't think that would be popular either.

Generally in Java, integral types don't throw overflows, and there's a lot of
code (e.g., 'hashCode()') that depend on that.

 

[Lew]

Was the misspelling intentional?

Out of CPAN into the fire!