ජාවා හි + =, - =, * =, / = සංයුක්ත පැවරුම් ක්‍රියාකරුවන්ට වාත්තු කිරීම අවශ්‍ය නොවන්නේ ඇයි?


3635

අද වන තුරු, මම එය උදාහරණයක් ලෙස සිතුවෙමි:

i += j;

මේ සඳහා කෙටිමඟක් පමණි:

i = i + j;

නමුත් අපි මෙය උත්සාහ කළහොත්:

int i = 5;
long j = 8;

එවිට i = i + j;සම්පාදනය නොකරන නමුත් i += j;දඩ සම්පාදනය කරනු ඇත.

ඇත්ත වශයෙන්ම i += j;මේ වගේ දෙයක් සඳහා කෙටිමඟක් බව එයින් අදහස් වේද i = (type of i) (i + j)?


135
ජාවා එහි පූර්වගාමීන්ට වඩා දැඩි භාෂාවක් වීම මෙයට ඉඩ දීම ගැන මම පුදුම වෙමි. Ariane5 Flight 501 හි සිදු වූවාක් මෙන්, වාත්තු කිරීමේදී ඇති වූ දෝෂයන් තීරණාත්මක අසාර්ථකත්වයට හේතු විය හැක.
SQLDiver

103
ජාවා හි ලියා ඇති ගුවන් පාලක පද්ධතියක, මෙය ඔබගේ කනස්සල්ලෙන් අවම වනු ඇත @SQLDiver
රොස්

10
ඇත්ත වශයෙන්ම i+=(long)j;පවා දඩය සම්පාදනය කරනු ඇත.
තරින්දු සතිස්චන්ද්‍ර

6
නිරවද්‍යතාව සඳහා එක් සංවර්ධකයින් සමූහයක් සහ භාවිතයේ පහසුව සඳහා නිරන්තරයෙන් තල්ලු කිරීම ඇත්තෙන්ම සිත්ගන්නා සුළුය. අපට භාෂාවේ අනුවාද දෙකක් පාහේ අවශ්‍ය වේ, එකක් විශ්මයජනක ලෙස නිරවද්‍ය හා භාවිතයට පහසු එකක්. ජාවා දෙපැත්තෙන්ම තල්ලු කිරීමෙන් එය එක් කණ්ඩායමකට නුසුදුසු බවට පත්වේ.
බිල් කේ

5
එයට වාත්තු කිරීම අවශ්‍ය නම්, ඔබ එය තබන්නේ කොතැනින්ද? i += (int) f;එකතු කිරීමට පෙර f කැස්ට් කරයි, එබැවින් එය සමාන නොවේ. (int) i += f;පැවරුමෙන් පසු ප්‍රති result ලය පළ කරයි, සමාන නොවේ. එකතු කිරීමෙන් පසුව නොව පැවරුමට පෙර අගය තැබීමට ඔබට අවශ්‍ය බව අඟවන වාත්තු කිරීමක් තැබීමට ස්ථානයක් නොමැත.
නොරිල් ටෙම්පස්ට්

Answers:


2443

සෑම විටම මෙම ප්‍රශ්න සමඟ, ජේඑල්එස් පිළිතුර දරයි. මෙම අවස්ථාවේ දී §15.26.2 සංයුක්ත පැවරුම් ක්‍රියාකරුවන් . උපුටා ගැනීමක්:

ආකෘති පත්‍රයේ සංයුක්ත පැවරුම් ප්‍රකාශනය E1 op= E2සමාන වන්නේ, වර්ගය E1 = (T)((E1) op (E2))කොතැනද , එය තක්සේරු කරනු ලබන්නේ එක් වරක් පමණි.TE1E1

§15.26.2 සිට උපුටා ගත් උදාහරණයක්

[...] පහත කේතය නිවැරදි ය:

short x = 3;
x += 4.6;

x හි අගය 7 ට සමාන වන නිසා එය සමාන වේ:

short x = 3;
x = (short)(x + 4.6);

වෙනත් වචන වලින් කිවහොත්, ඔබේ උපකල්පනය නිවැරදි ය.


42
එබැවින් i+=jමා විසින්ම පරීක්ෂා කර බැලූ විට සම්පාදනය කරයි, නමුත් එහි ප්‍රති result ලය වනුයේ නිරවද්‍යතාව නැති වීමයි. එය එසේ නම්, එය i = i + j තුළ ද සිදුවීමට ඉඩ නොදෙන්නේ ඇයි? ඇයි අපි එතනට දෝෂාරෝපණය කරන්නේ?
bad_keypoints

46
@ronnieaka: භාෂා නිර්මාණකරුවන්ට හැඟී ගියේ එක් අවස්ථාවක ( i += j), අනෙක් අවස්ථාව හා සසඳන විට නිරවද්‍යතාව නැතිවීම අපේක්‍ෂා කරන බව උපකල්පනය කිරීම වඩා ආරක්ෂිත බවයි ( i = i + j)
ලූකස් ඊඩර්

12
නැහැ, එහි හරි, මට ඉදිරියෙන්! කණගාටුයි, මම එය කලින් දුටුවේ නැත. ඔබේ පිළිතුරේ දී E1 op= E2 is equivalent to E1 = (T)((E1) op (E2))මෙන්, එය ද ටයිප්කාස්ටිං (දිගු සිට int දක්වා) ගම්‍ය වේ. I = i + j හි, අපි එය පැහැදිලිවම කළ යුතුව ඇත, එනම්, එහි (T)කොටස සපයන්නේ E1 = ((E1) op (E2))එය නොවේද?
bad_keypoints

11
ජාවා සම්පාදකයා යතුරු ලියනය එකතු කිරීමට හේතු විය හැකි හේතුව නම්, ඔබ නොගැලපෙන වර්ගවල අංක ගණිතය සිදු කිරීමට උත්සාහ කරන්නේ නම්, ගිවිසුම්ගත පෝරමය භාවිතා කර ප්‍රති result ල යතුරු ලියනය කිරීමට ක්‍රමයක් නොමැති බැවිනි. ප්‍රති result ල යතුරු ලියනය සාමාන්‍යයෙන් ගැටළු සහගත තර්කයේ යතුරු ලියනයකට වඩා නිවැරදි ය. නොගැලපෙන වර්ග භාවිතා කරන විට කිසිදු යතුරු ලියනයකින් සංකෝචනය නිෂ් less ල නොවනු ඇත, මන්ද එය සෑම විටම සම්පාදකයා දෝෂයක් දුරු කිරීමට හේතු වේ.
ThePyroEagle

6
එය වටකුරු නොවේ. එය වාත්තු කර ඇත (= කැපූ)
ලූකස් ඊඩර්

483

මෙම වාත්තු කිරීම සඳහා හොඳ උදාහරණයක් වන්නේ * = හෝ / = භාවිතා කිරීමයි

byte b = 10;
b *= 5.7;
System.out.println(b); // prints 57

හෝ

byte b = 100;
b /= 2.5;
System.out.println(b); // prints 40

හෝ

char ch = '0';
ch *= 1.1;
System.out.println(ch); // prints '4'

හෝ

char ch = 'A';
ch *= 1.5;
System.out.println(ch); // prints 'a'

11
Ks අක්ෂාත් අගර්වාල් ච. 65 * 1.5 = 97.5 -> තේරුණාද?
සජල් දත්ත

79
ඔව්, නමුත් සමහර ආරම්භකයකු මෙහි පැමිණ, මෙය කියවා, ඔබට ඕනෑම චරිතයක් ඉහළ අකුරේ සිට කුඩා අකුරට 1.5 කින් ගුණ කිරීමෙන් පරිවර්තනය කළ හැකි යැයි සිතමින් ඉවතට යනවා මට පෙනේ.
ඩාවුඩ් ඉබ්න් කරීම්

103
Av ඩේවිඩ් වොලස් ඕනෑම චරිතයක් පවතින තාක් කල් A;)
පීටර් ලෝරි

14
EtPeterLawrey & avDavidWallace මම ඔබේ රහස හෙළි කරමි - ch += 32 = D
Minhas Kamal

256

ඉතා හොඳ ප්‍රශ්නයක්. මෙම ජාවා භාෂාව පිරිවිතර ඔබේ යෝජනාව තහවුරු කරයි.

උදාහරණයක් ලෙස, පහත කේතය නිවැරදි ය:

short x = 3;
x += 4.6;

x හි අගය 7 ට සමාන වන නිසා එය සමාන වේ:

short x = 3;
x = (short)(x + 4.6);

15
හෝ වඩාත් විනෝදජනක: "int x = 33333333; x + = 1.0f;".
supercat

5
up සුපර්කැට්, මෙය මොන උපක්‍රමයද? වැරැදි ලෙස වටකුරු පුළුල් කිරීමේ පරිවර්තනයක්, පසුව ප්‍රති result ලය සැබවින්ම වෙනස් නොවන එකතු කිරීමක්, සාමාන්‍ය මිනිස් මනසට වඩාත්ම අනපේක්ෂිත ප්‍රති result ලයක් ලබා දීම සඳහා නැවත int වෙත යොමු කිරීම.
neXus

1
XneXus: IMHO, පරිවර්තන නීති double->floatපුළුල් කිරීම ලෙස සැලකිය යුතු අතර, වර්ගයෙහි අගයන් floatතාත්වික සංඛ්‍යා වර්ගයට වඩා අඩු වශයෙන් හඳුනා ගනී double. යමෙක් doubleසම්පූර්ණ තැපැල් ලිපිනයක් floatලෙස සහ ඉලක්කම් 5 ක තැපැල් කේතයක් ලෙස සලකන්නේ නම්, සම්පූර්ණ ලිපිනයක් ලබා දී ඇති තැපැල් කේතයක් සඳහා වන ඉල්ලීමක් සපුරාලිය හැකි නමුත්, තැපැල් කේතයක් පමණක් ලබා දී සම්පූර්ණ ලිපිනයක් සඳහා ඉල්ලීමක් නිවැරදිව සඳහන් කළ නොහැක. . වීදි ලිපිනයක් තැපැල් කේතයක් බවට පරිවර්තනය කිරීම අලාභදායක ක්‍රියාවකි, නමුත් ...
සුපර් කැට්

1
... සම්පූර්ණ ලිපිනයක් අවශ්‍ය අයෙකු සාමාන්‍යයෙන් තැපැල් කේතයක් ඉල්ලන්නේ නැත. සිට float->doubleපරිවර්තනය කිරීම එක්සත් ජනපද තැපැල් කේතය 90210 "එක්සත් ජනපද තැපැල් කාර්යාලය, බෙවර්ලි හිල්ස් සීඒ 90210" සමඟ පරිවර්තනය කිරීමට සමාන වේ.
supercat

181

ඔව්,

මූලික වශයෙන් අපි ලියන විට

i += l; 

සම්පාදකයා මෙය බවට පරිවර්තනය කරයි

i = (int)(i + l);

මම දැන් පරීක්ෂා කළා .class ගොනු කේතය .

දැන ගැනීමට ඇත්තෙන්ම හොඳ දෙයක්


3
මෙය කුමන පන්ති ගොනුවදැයි මට කියන්න පුළුවන්ද?
නැනෝෆරාඩ්

6
xhexafraction: පන්ති ගොනුව යන්නෙන් ඔබ අදහස් කරන්නේ කුමක්ද? මගේ ජාවා පංතියේ අනුකූල අනුවාදයට වඩා මගේ ලිපියේ සඳහන් පංති ගොනුව ගැන ඔබ ඇසුවොත්
උමේෂ් අවස්ති

3
ඔහ්, ඔබ "පංති ගොනු කේතය" සඳහන් කළ අතර එමඟින් නිශ්චිත පන්ති ගොනුවක් සම්බන්ධ යැයි මට විශ්වාස විය. මට තේරෙනවා ඔයා දැන් අදහස් කරන දේ.
නැනෝෆරාඩ්

Og බොග්ඩාන් එය නිසි ලෙස භාවිතා කරන අකුරු සමඟ ගැටළුවක් නොවිය යුතුය. ක්‍රමලේඛනය සඳහා වැරදි අකුරු තෝරා ගන්නා ක්‍රමලේඛකයෙකු ඉදිරියට යා යුතු ආකාරය ගැන පැහැදිලිව සිතා බැලිය යුතුය ...
glglgl

7
casesglglgl එවැනි අවස්ථා වලදී වෙන්කර හඳුනා ගැනීම සඳහා යමෙකු අකුරු මත විශ්වාසය තැබිය යුතු බවට මම එකඟ නොවෙමි ... නමුත් හොඳම දේ යැයි සිතන දේ තෝරා ගැනීමට සෑම කෙනෙකුටම නිදහස තිබේ.
බොග්ඩන් ඇලෙක්සැන්ඩ්රු

92

ඔබ කාස්ට් කිරීමට අවශ්ය longකිරීමට int explicitlyවූ අවස්ථාවක i = i + l එය නිවැරදි ප්රතිදානය සම්පාදනය ලබා දෙනු ඇත. මෙන්

i = i + (int)l;

හෝ

i = (int)((long)i + l); // this is what happens in case of += , dont need (long) casting since upper casting is done implicitly.

නමුත් +=එය හොඳින් ක්‍රියාත්මක වන්නේ ක්‍රියාකරු ව්‍යංගයෙන් දකුණු විචල්‍යයේ සිට වම් විචල්‍යයේ වර්ගය දක්වා වාත්තු කිරීම නිසා පැහැදිලිවම වාත්තු කිරීම අවශ්‍ය නොවේ.


7
මෙම අවස්ථාවේ දී, "ව්‍යංග වාත්තු" පාඩු විය හැකිය. යථාර්ථයේ දී, uk ලූකස්ඊඩර් ඔහුගේ පිළිතුරෙහි සඳහන් කර ඇති පරිදි, කළ යුතු දේ intසිදු කරනු ලබන්නේ +. සම්පාදකයා එය කළ යුතු නම් අනතුරු ඇඟවීමක් longකරයි int.
රොමේන්

63

මෙහි ඇති ගැටළුව ටයිප් වාත්තු කිරීමයි.

ඔබ int සහ long එකතු කළ විට,

  1. Int වස්තුව දිගු කලක් වාත්තු කර ඇති අතර දෙකම එකතු වන අතර ඔබට දිගු වස්තුවක් ලැබේ.
  2. නමුත් දිගු වස්තුවක් int ට ඇඟවුම් කළ නොහැක. එබැවින්, ඔබ එය පැහැදිලිව කළ යුතුය.

නමුත් +=කේතනය කර ඇත්තේ එය වාත්තු කිරීම සඳහා වන ආකාරයට ය.i=(int)(i+m)


54

පැවරුම් මෙහෙයුමක දකුණු පැත්තේ ප්‍රකාශන වර්ගය ආරක්ෂිතව පැවරුමේ වම් පස ඇති විචල්‍යයේ වර්ගයට ආරක්ෂිතව ප්‍රවර්ධනය කළ හැකි විට ජාවා වර්ගයේ පරිවර්තන ස්වයංක්‍රීයව සිදු වේ. මේ අනුව අපට ආරක්ෂිතව පැවරිය හැකිය:

 byte -> short -> int -> long -> float -> double. 

එය අනෙක් පැත්තෙන් ක්‍රියා නොකරනු ඇත. නිදසුනක් ලෙස අපට දිගු කාලයක් ස්වයංක්‍රීයව int බවට පරිවර්තනය කළ නොහැක, මන්ද පළමුවැන්නාට දෙවැන්නටත් වඩා වැඩි ගබඩා ප්‍රමාණයක් අවශ්‍ය වන අතර එමඟින් තොරතුරු නැති විය හැකිය. එවැනි පරිවර්තනයකට බල කිරීම සඳහා අප පැහැදිලි පරිවර්තනයක් කළ යුතුය.
වර්ගය - පරිවර්තනය


2
හේයි, නමුත් longවඩා 2 ගුණයක් විශාලයි float.
දර්ශන නාමය

11
floatසඳහා හැකි සෑම පැවැත්වීමට නොහැකි intවටිනාකම, සහ doubleහැකි සෑම පැවැත්වීමට නොහැකි longවටිනාකම.
ඇලෙක්ස් එම්ඩීසී

2
"ආරක්ෂිතව පරිවර්තනය කිරීම" යන්නෙන් ඔබ අදහස් කරන්නේ කුමක්ද? පිළිතුරේ අවසාන කොටසේ සිට මට අනුමාන කළ හැක්කේ ඔබ අදහස් කළේ ස්වයංක්‍රීය පරිවර්තනයක් (ව්‍යංග වාත්තු) පාවෙන අවස්ථාවකදී සත්‍ය නොවන බවයි -> දිගු. float pi = 3.14f; දිගු b = pi; සම්පාදක දෝෂයක් ඇති කරයි.
ලූක්

1
පාවෙන ලක්ෂ්‍ය ප්‍රාථමික වර්ග පූර්ණ සංඛ්‍යා ප්‍රාථමික වර්ග සමඟ වෙන්කර හඳුනා ගැනීම වඩා හොඳය. ඔවුන් එකම දෙයක් නොවේ.
ThePyroEagle

ජාවාහි සරල පරිවර්තන නීති ඇත, එමඟින් බොහෝ රටාවන්හි කාස්ට් භාවිතා කිරීම අවශ්‍ය වේ, එහිදී වාත්තු නොමැතිව හැසිරීම අපේක්ෂාවන්ට ගැලපේ, නමුත් සාමාන්‍යයෙන් වැරදි වන බොහෝ රටාවන්හි කාස්ට් අවශ්‍ය නොවේ. උදාහරණයක් ලෙස, සම්පාදක පිළිගනු ඇත double d=33333333+1.0f;ප්රතිඵලය 33333332,0 ඉඩ අදහස් කරන ලදී දේ වන්නේ නැහැ නමුත්, පැමිණිල්ලක් නොමැතිව (මේ අතර, 33333334.0f වන arithmetically-නිවැරදි පිළිතුර හෝ ලෙස නියෝජනකාරී වනු ඇත floatහෝ int).
supercat

46

සමහර විට සම්මුඛ පරීක්ෂණයකදී එවැනි ප්රශ්නයක් ඇසිය හැකිය.

උදාහරණයක් ලෙස, ඔබ ලියන විට:

int a = 2;
long b = 3;
a = a + b;

ස්වයංක්‍රීය යතුරු ලියනය කිරීමක් නොමැත. C ++ හි ඉහත කේතය සම්පාදනය කිරීමේ කිසිදු දෝෂයක් ඇති නොවනු ඇත, නමුත් ජාවාහිදී ඔබට එවැනි දෙයක් ලැබෙනු ඇතIncompatible type exception .

එබැවින් එය වළක්වා ගැනීම සඳහා, ඔබ ඔබේ කේතය මේ ආකාරයෙන් ලිවිය යුතුය:

int a = 2;
long b = 3;
a += b;// No compilation error or any exception due to the auto typecasting

6
opC ++ හි භාවිතය ජාවා හි භාවිතය හා සැසඳීම පිළිබඳ තීක්ෂ්ණ බුද්ධියට ස්තූතියි . මම සෑම විටම මෙම සුළු සුළු දේවල් දැකීමට කැමතියි. ඔවුන් බොහෝ විට අතහැර දැමිය හැකි සංවාදයට යමක් දායක වේ යැයි මම සිතමි.
තෝමස්

2
කෙසේ වෙතත් එම ප්රශ්නය ම වේ මෙම ඉල්ලා, රසවත් පැවති සම්මුඛ සාකච්ඡාවක දී , මෝඩ ය. පුද්ගලයාට හොඳ තත්ත්වයේ කේතයක් නිෂ්පාදනය කළ හැකි බව එය සනාථ නොකරයි - එය ඔප්පු කරන්නේ ඔරකල් සහතික විභාගයකට සූදානම් වීමට ඔහුට ප්‍රමාණවත් ඉවසීමක් ඇති බවය. භයානක ස්වයංක්‍රීය පරිවර්තනයක් භාවිතා කිරීමෙන් නොගැලපෙන වර්ග "වළක්වා ගැනීම" සහ එමඟින් පිටාර ගැලීමේ දෝෂය සැඟවීම, හොඳ තත්ත්වයේ කේතයක් නිපදවීමට පුද්ගලයාට නොහැකි බව බොහෝ විට ඔප්පු වේ. මෙම සියලු ස්වයංක්‍රීය පරිවර්තනයන් සහ ස්වයංක්‍රීය බොක්සිං සඳහා ජාවා කතුවරුන්ට හානි කරන්න!
හොන්සා සිඩෙක්

25

ප්‍රධාන වෙනස නම් a = a + b, යතුරු ලියනය කිරීමක් සිදු නොවීමයි, එබැවින් යතුරු ලියනය නොකිරීම නිසා සම්පාදකයා ඔබ කෙරෙහි කෝපයට පත් වේ. නමුත් a += bඇත්තෙන්ම එය කරන්නේ bඅනුකූල වන වර්ගයකට යතුරු ලියනය aකිරීමයි. ඉතින් ඔබ එසේ කරන්නේ නම්

int a=5;
long b=10;
a+=b;
System.out.println(a);

ඔබ ඇත්තටම කරන්නේ:

int a=5;
long b=10;
a=a+(int)b;
System.out.println(a);

5
සංයුක්ත පැවරුම් ක්‍රියාකරුවන් විසින් ද්විමය ක්‍රියාකාරිත්වයේ ප්‍රති result ලය පටු පරිවර්තනයක් සිදු කරයි, දකුණත ක්‍රියාකාරිත්වය නොවේ. එබැවින් ඔබේ උදාහරණයේ දී, 'a + = b' යනු 'a = a + (int) b' ට සමාන නොවන නමුත් මෙහි වෙනත් පිළිතුරු මගින් පැහැදිලි කර ඇති පරිදි 'a = (int) (a + b)' ට සමාන වේ.
ලිව් බ්ලොච්

13

මෙහි සියුම් කරුණ ...

ද්විත්ව වන විට සහ පූර්ණ සංඛ්‍යාවක් වන i+jවිට ව්‍යංග යතුරු ලියනයකි. ජාවා සෑම විටමji පූර්ණ සංඛ්‍යාවක් දෙගුණයක් බවට පරිවර්තනය කරන්නේ ඒවා අතර මෙහෙයුමක් ඇති විටය.

පූර්ණ සංඛ්‍යාවක් සහ දෙගුණයක් වන්නේ i+=jකොතැනද iයන්න පැහැදිලි කිරීම සඳහා jවිස්තර කළ හැකිය

i = <int>(<double>i + j)

බලන්න: ව්‍යංග වාත්තු කිරීම පිළිබඳ මෙම විස්තරය

පැහැදිලිකම සඳහා ඔබට මෙම අවස්ථාවේදී යතුරු ලියනය jකිරීමට අවශ්‍ය විය හැකිය (int).


1
මම හිතන්නේ වඩාත් සිත්ගන්නා කරුණක් විය හැකිය int someInt = 16777217; float someFloat = 0.0f; someInt += someFloat;. බිංදුවට එකතු කිරීම someIntඑහි වටිනාකමට බලපාන්නේ නැත, නමුත් ප්‍රවර්ධනය someIntකිරීමෙන් floatඑහි වටිනාකම වෙනස් විය හැකිය.
සුපර් කැට්

5

ජාවා භාෂාව පිරිවිතර නිර්වචනය E1 op= E2සමාන විය E1 = (T) ((E1) op (E2))එහිදී Tවර්ගයකි E1හා E1වරක් ඇගැයීමකට ලක් .

එය තාක්‍ෂණික පිළිතුරකි, නමුත් එය එසේ වන්නේ මන්දැයි ඔබ කල්පනා කරනවා විය හැකිය. හොඳයි, අපි පහත වැඩසටහන සලකා බලමු.

public class PlusEquals {
    public static void main(String[] args) {
        byte a = 1;
        byte b = 2;
        a = a + b;
        System.out.println(a);
    }
}

මෙම වැඩසටහන මුද්‍රණය කරන්නේ කුමක්ද?

ඔබ 3 අනුමාන කළාද? ඉතා නරකයි, මෙම වැඩසටහන සම්පාදනය නොකරයි. මන්ද? හොඳයි, එය එසේ වන්නේ ජාවා හි බයිට් එකතු කිරීම අර්ථ දැක්වීමක් ලෙස යint . මෙය, මම විශ්වාස කළේ ජාවා අතථ්‍ය යන්ත්‍රය බයිට් කේත මත සුරැකීම සඳහා බයිට් මෙහෙයුම් නිර්වචනය නොකරන බැවිනි (ඒවායින් සීමිත සංඛ්‍යාවක් ඇත, සියල්ලට පසු), පූර්ණ සංඛ්‍යා මෙහෙයුම් භාවිතා කිරීම භාෂාවක නිරාවරණය කිරීමේ විස්තරයකි.

නමුත් a = a + bක්‍රියා නොකරන්නේ නම් , එයින් අදහස් a += bවන්නේ එය බයිට් E1 += E2ලෙස අර්ථ දක්වා ඇත්නම් එය කිසි විටෙකත් ක්‍රියා නොකරන බවයි E1 = E1 + E2. පෙර උදාහරණයෙන් පෙන්නුම් කරන පරිදි, එය එසේ වනු ඇත. කිරීමට ඇති නම්න් ලෙස +=බයිට් හා කොට කලිසම් සඳහා ක්රියාකරු වැඩ, ඒ හා සම්බන්ධ ගම්ය කාස්ට් නැත. එය එතරම් විශාල කඩුල්ලක් නොවේ, නමුත් ජාවා 1.0 වැඩ අතරතුරදී, අවධානය යොමු වූයේ භාෂාව මුදා හැරීම ආරම්භ කිරීම සඳහා ය. දැන්, පසුගාමී අනුකූලතාවය නිසා, ජාවා 1.0 හි හඳුන්වා දුන් මෙම හැක් ඉවත් කළ නොහැක.

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.