"bb = bb + 1" vs "bb += 1"

[Razvan]

Hi !






The following code does not compile (as expected):


class SimpleJava
{

public static void main(String args[])
{
System.out.println("SimpleJava ....");

byte bb = 0;
bb = bb + 1;
System.out.println("bb = " + bb);
}
}

While the following one is compiling:

class SimpleJava
{

public static void main(String args[])
{
System.out.println("SimpleJava ....");

byte bb = 0;
bb += 1;
System.out.println("bb = " + bb);
}
}

The += operator is specific to each primitive, so it "know" how to
work with integers. The operator + is generic so a cast is necessary
?!!

Any other logical explanation ?




Regards,
Razvan

 

[Stefan Schulz]

The += operator is specific to each primitive, so it "know" how to
work with integers. The operator + is generic so a cast is necessary
?!!
Any other logical explanation ?

No, the compiler simply does not put full equivalence to x = x + y;
and x += y. The former is a normal assignment, and normal
assignment compatibility rules are enforced. This means that in your
example, the type of the result (int) is tried to fit into a
byte... since this is not generally possible, a warning is emitted.

The += operator however does something different. It increments
a variable by a set value. You could just as easily have written
a += 1000; and it would still have been valid (with several
overflows).

I agree that this is not the best behaviour. I would prefer that
assignment-operation had the same restrictions as assignment.

 

[Tov Are Jacobsen]

Den Sun, 03 Oct 2004 13:04:50 -0700, skrev Razvan:
[...]

byte bb = 0;
bb = bb + 1; [..]
byte bb = 0;
bb += 1;

[...]

In the first example the result is integer, that's why a cast is required.
In the second example the result is byte, and doesn't require a cast.

bb = byte (bb + 1);

Regards,

Tov Are Jacobsen

 

[Peter Davis]

bb = byte (bb + 1);

I think you meant:

bb = (byte) (bb + 1);

 

[Chris Smith]

Den Sun, 03 Oct 2004 13:04:50 -0700, skrev Razvan:
[...]

byte bb = 0;
bb = bb + 1; [..]
byte bb = 0;
bb += 1;

[...]

In the first example the result is integer, that's why a cast is required.
In the second example the result is byte, and doesn't require a cast.

True that the result of the second is a byte, but it doesn't matter.
The result of the expression is ignored. What's important is simply
that the '+=' operator defined an implicit type conversion to the target
type during its side effect. This is explained in 15.26.2 of the JLS,
including an explicit mention of this potentially surprising meaning for
narrowing primitive conversions.

To the OP: Though people may give you theories on a "why" for this, the
real answer is that it's that way because the JLS says it is. Anything
else is merely a guess regarding what someone thought about when they
wrote the section of the JLS. The JLS is not always consistent, and
it's not wrong when it isn't consistent (though consistency is certainly
one of the many virtues juggled in designing a programming language).

--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Tom McGlynn]

No, the compiler simply does not put full equivalence to x = x + y;
and x += y. The former is a normal assignment, and normal
assignment compatibility rules are enforced. This means that in your
example, the type of the result (int) is tried to fit into a
byte... since this is not generally possible, a warning is emitted.

The += operator however does something different. It increments
a variable by a set value. You could just as easily have written
a += 1000; and it would still have been valid (with several
overflows).

I agree that this is not the best behaviour. I would prefer that
assignment-operation had the same restrictions as assignment.

Given Java's automatic promotion of byte, short and char expressions
to integer, this would preclude use of the += (and similar operation/assignment)
operators with those types, since there is no place to put the
needed cast operator. So there are special rules in the language to
accommodate this situation.

Automatic promotion is a real wart in Java since it means that
byte, short, and char types are second class primitives. The language
would be cleaner (IMHO) without automatic promotion. Then the
statements
byte b;
b += 1B;
b = b + 1B;
could be valid but both
b += 1;
b = b + 1;
would be invalid since the mixed type operands would be mean the expression was
of type integer.

Of course it is far too late for such a change.


Regards,
Tom McGlynn

 

[Thomas G. Marshall]

Chris Smith coughed up:

Den Sun, 03 Oct 2004 13:04:50 -0700, skrev Razvan:
[...]

byte bb = 0;
bb = bb + 1; [..]
byte bb = 0;
bb += 1;

[...]

In the first example the result is integer, that's why a cast is
required. In the second example the result is byte, and doesn't
require a cast.

True that the result of the second is a byte, but it doesn't matter.
The result of the expression is ignored. What's important is simply
that the '+=' operator defined an implicit type conversion to the
target type during its side effect. This is explained in 15.26.2 of
the JLS, including an explicit mention of this potentially surprising
meaning for narrowing primitive conversions.

To the OP: Though people may give you theories on a "why" for this,
the real answer is that it's that way because the JLS says it is.

Nothing like meeting everyone else with a scatter-gun. LOL. But I
applaud your diving into the /only/ true authority in these parts. That
pesky JLS.

Anything else is merely a guess regarding what someone thought about
when they wrote the section of the JLS. The JLS is not always
consistent, and it's not wrong when it isn't consistent (though
consistency is certainly one of the many virtues juggled in designing
a programming language).

--
Iamamanofconstantsorrow,I'veseentroubleallmydays.Ibidfarewelltoold
Kentucky,TheplacewhereIwasbornandraised.ForsixlongyearsI'vebeenin
trouble,NopleasureshereonearthIfound.ForinthisworldI'mboundtoramble,
Ihavenofriendstohelpmenow....MaybeyourfriendsthinkI'mjustastrangerMyface,
you'llneverseenomore.ButthereisonepromisethatisgivenI'llmeetyouonGod's
goldenshore.