JavaRush /جاوا بلاگ /Random-UR /اشیاء کا موازنہ: مشق
articles
سطح

اشیاء کا موازنہ: مشق

گروپ میں شائع ہوا۔
اشیاء کا موازنہ کرنے کے لیے وقف کردہ مضامین میں سے یہ دوسرا مضمون ہے۔ ان میں سے پہلے موازنہ کی نظریاتی بنیاد پر بحث کی گئی - یہ کیسے کیا جاتا ہے، کیوں اور کہاں استعمال ہوتا ہے۔ اس مضمون میں ہم نمبروں، اشیاء، خاص صورتوں، باریکیوں اور غیر واضح نکات کا موازنہ کرنے کے بارے میں براہ راست بات کریں گے۔ مزید واضح طور پر، یہاں وہ ہے جس کے بارے میں ہم بات کریں گے:
اشیاء کا موازنہ: مشق - 1
  • سٹرنگ کا موازنہ: ' ==' اورequals
  • طریقہString.intern
  • اصلی قدیم چیزوں کا موازنہ
  • +0.0اور-0.0
  • مطلبNaN
  • Java 5.0 ==' کے ذریعے طریقے اور موازنہ پیدا کرنا
  • Java 5.0 آٹو باکسنگ/ان باکسنگ: ' =='، ' >=' اور ' <=' آبجیکٹ ریپرز کے لیے۔
  • Java 5.0 اینوم عناصر کا موازنہ (قسم enum)
تو آئیے شروع کریں!

سٹرنگ کا موازنہ: ' ==' اورequals

آہ، یہ سطریں... سب سے زیادہ استعمال ہونے والی اقسام میں سے ایک، جو بہت سے مسائل کا باعث بنتی ہے۔ اصولی طور پر، ان کے بارے میں ایک الگ مضمون ہے ۔ اور یہاں میں موازنہ کے مسائل پر بات کروں گا۔ بلاشبہ، تاروں کا استعمال کرتے ہوئے موازنہ کیا جا سکتا ہے equals۔ مزید یہ کہ، ان کا موازنہ کے ذریعے کیا جانا چاہیے equals۔ تاہم، ایسی باریکیاں ہیں جو جاننے کے قابل ہیں۔ سب سے پہلے، ایک جیسی تاریں دراصل ایک ہی شے ہیں۔ درج ذیل کوڈ کو چلا کر آسانی سے اس کی تصدیق کی جا سکتی ہے۔
String str1 = "string";
String str2 = "string";
System.out.println(str1==str2 ? "the same" : "not the same");
نتیجہ "ایک جیسا" ہوگا ۔ جس کا مطلب ہے کہ تار کے حوالہ جات برابر ہیں۔ یہ کمپائلر کی سطح پر کیا جاتا ہے، ظاہر ہے میموری کو بچانے کے لیے۔ مرتب کرنے والا سٹرنگ کی ایک مثال بناتا ہے، اور اس مثال کے لیے str1ایک حوالہ تفویض کرتا ہے۔ str2تاہم، یہ صرف ان تاروں پر لاگو ہوتا ہے جنہیں کوڈ میں لٹریلز قرار دیا گیا ہے۔ اگر آپ ٹکڑوں سے سٹرنگ کمپوز کرتے ہیں تو اس کا لنک مختلف ہوگا۔ تصدیق - یہ مثال:
String str1 = "string";
String str2 = "str";
String str3 = "ing";
System.out.println(str1==(str2+str3) ? "the same" : "not the same");
نتیجہ "ایک جیسا نہیں" ہوگا ۔ آپ کاپی کنسٹرکٹر کا استعمال کرتے ہوئے ایک نیا آبجیکٹ بھی بنا سکتے ہیں۔
String str1 = "string";
String str2 = new String("string");
System.out.println(str1==str2 ? "the same" : "not the same");
نتیجہ بھی "ایک جیسا نہیں" ہوگا ۔ اس طرح، بعض اوقات حوالہ موازنہ کے ذریعے تاروں کا موازنہ کیا جا سکتا ہے۔ لیکن اس پر بھروسہ نہ کرنا بہتر ہے۔ میں ایک بہت ہی دلچسپ طریقہ کو چھونا چاہتا ہوں جو آپ کو سٹرنگ کی نام نہاد کینونیکل نمائندگی حاصل کرنے کی اجازت دیتا ہے - String.intern۔ آئیے اس کے بارے میں مزید تفصیل سے بات کرتے ہیں۔

String.intern طریقہ

آئیے اس حقیقت کے ساتھ شروع کریں کہ کلاس Stringسٹرنگ پول کو سپورٹ کرتی ہے۔ کلاسوں میں بیان کردہ تمام سٹرنگ لٹریلز، اور نہ صرف وہ، اس پول میں شامل کیے گئے ہیں۔ لہذا، طریقہ internآپ کو اس پول سے ایک سٹرنگ حاصل کرنے کی اجازت دیتا ہے جو موجودہ کے برابر ہے (جس پر طریقہ کہا جاتا ہے intern) کے نقطہ نظر سے equals۔ اگر پول میں ایسی قطار موجود نہیں ہے، تو موجودہ ایک کو وہاں رکھ دیا جاتا ہے اور اس کا ایک لنک واپس کردیا جاتا ہے۔ اس طرح، یہاں تک کہ اگر دو مساوی تاروں کے حوالہ جات مختلف ہیں (جیسا کہ اوپر کی دو مثالوں میں)، پھر ان تاروں کو کال کرنے سے internایک ہی شے کا حوالہ ملے گا:
String str1 = "string";
String str2 = new String("string");
System.out.println(str1.intern()==str2.intern() ? "the same" : "not the same");
کوڈ کے اس ٹکڑے کو انجام دینے کا نتیجہ "ایک جیسا" ہوگا ۔ میں قطعی طور پر نہیں کہہ سکتا کہ ایسا کیوں کیا گیا۔ طریقہ internمقامی ہے، اور سچ پوچھیں تو، میں C کوڈ کے جنگل میں نہیں جانا چاہتا۔ غالباً یہ میموری کی کھپت اور کارکردگی کو بہتر بنانے کے لیے کیا گیا ہے۔ کسی بھی صورت میں، یہ نفاذ کی اس خصوصیت کے بارے میں جاننے کے قابل ہے۔ آئیے اگلے حصے کی طرف چلتے ہیں۔

اصلی قدیم چیزوں کا موازنہ

شروع کرنے کے لیے، میں ایک سوال پوچھنا چاہتا ہوں۔ بہت آسان. مندرجہ ذیل رقم کیا ہے - 0.3f + 0.4f؟ کیوں؟ 0.7f؟ آؤ دیکھیں:
float f1 = 0.7f;
float f2 = 0.3f + 0.4f;
System.out.println("f1==f2: "+(f1==f2));
اس کے نتیجے میں؟ پسند ہے؟ میں بھی. جن لوگوں نے یہ ٹکڑا مکمل نہیں کیا ان کے لیے میں کہوں گا کہ نتیجہ یہ نکلے گا...
f1==f2: false
ایسا کیوں ہو رہا ہے؟... آئیے ایک اور ٹیسٹ کرتے ہیں:
float f1 = 0.3f;
float f2 = 0.4f;
float f3 = f1 + f2;
float f4 = 0.7f;
System.out.println("f1="+(double)f1);
System.out.println("f2="+(double)f2);
System.out.println("f3="+(double)f3);
System.out.println("f4="+(double)f4);
میں تبدیلی کو نوٹ کریں double۔ یہ زیادہ اعشاریہ جگہوں کو آؤٹ پٹ کرنے کے لیے کیا جاتا ہے۔ نتیجہ:
f1=0.30000001192092896
f2=0.4000000059604645
f3=0.7000000476837158
f4=0.699999988079071
سخت الفاظ میں، نتیجہ متوقع ہے. جزوی حصے کی نمائندگی ایک محدود سیریز 2-n کا استعمال کرتے ہوئے کی جاتی ہے، اور اس وجہ سے من مانی طور پر منتخب کردہ نمبر کی صحیح نمائندگی کے بارے میں بات کرنے کی ضرورت نہیں ہے۔ جیسا کہ مثال سے دیکھا جا سکتا ہے، نمائندگی کی درستگی float7 اعشاریہ ہے۔ سختی سے بولیں تو، نمائندگی float مینٹیسا کو 24 بٹس مختص کرتی ہے۔ اس طرح، کم از کم مطلق نمبر جس کی نمائندگی کی جا سکتی ہے float (ڈگری کو مدنظر رکھے بغیر، کیونکہ ہم درستگی کے بارے میں بات کر رہے ہیں) 2-24≈6*10-8 ہے۔ یہ اس قدم کے ساتھ ہے کہ نمائندگی میں اقدار اصل میں جاتی ہیں float. اور چونکہ کوانٹائزیشن ہے اس لیے ایک خرابی بھی ہے۔ لہذا نتیجہ: نمائندگی میں نمبروں کا floatموازنہ صرف ایک خاص درستگی سے کیا جاسکتا ہے۔ میں ان کو 6 ویں اعشاریہ (10-6) پر گول کرنے کی سفارش کروں گا، یا ترجیحی طور پر، ان کے درمیان فرق کی مطلق قدر کو چیک کریں:
float f1 = 0.3f;
float f2 = 0.4f;
float f3 = f1 + f2;
float f4 = 0.7f;
System.out.println("|f3-f4|<1e-6: "+( Math.abs(f3-f4) < 1e-6 ));
اس صورت میں، نتیجہ حوصلہ افزا ہے:
|f3-f4|<1e-6: true
بالکل، تصویر بالکل اسی قسم کے ساتھ ہے double. فرق صرف یہ ہے کہ مینٹیسا کے لیے 53 بٹس مختص کیے گئے ہیں، لہذا، نمائندگی کی درستگی 2-53≈10-16 ہے۔ ہاں، کوانٹائزیشن کی قدر بہت چھوٹی ہے، لیکن یہ وہاں ہے۔ اور یہ ایک ظالمانہ مذاق کھیل سکتا ہے۔ ویسے، JUnit ٹیسٹ لائبریری میں ، حقیقی نمبروں کا موازنہ کرنے کے طریقوں میں، درستگی کو واضح طور پر بیان کیا گیا ہے۔ وہ. موازنہ کا طریقہ تین پیرامیٹرز پر مشتمل ہے - نمبر، اس کے برابر ہونا چاہیے، اور موازنہ کی درستگی۔ ویسے، میں ڈگری کی نشاندہی کرتے ہوئے سائنسی شکل میں نمبر لکھنے سے وابستہ باریکیوں کا ذکر کرنا چاہوں گا۔ سوال۔ 10-6 کیسے لکھیں؟ پریکٹس سے پتہ چلتا ہے کہ 80% سے زیادہ جواب - 10e-6۔ دریں اثنا، صحیح جواب 1e-6 ہے! اور 10e-6 10-5 ہے! ہم نے اس ریک پر ایک پروجیکٹ میں قدم رکھا، بالکل غیر متوقع طور پر۔ انہوں نے کافی دیر تک اس خامی کو دیکھا، 20 بار مستقل کو دیکھا اور ان کی درستگی کے بارے میں کسی کے ذہن میں کوئی شبہ نہیں تھا، یہاں تک کہ ایک دن، بڑی حد تک اتفاقی طور پر، مستقل 10e-3 پرنٹ ہو گیا اور انہیں دو مل گئے۔ متوقع تین کے بجائے اعشاریہ کے بعد کے ہندسے۔ لہذا، ہوشیار رہو! آئیے آگے بڑھیں۔

+0.0 اور -0.0

حقیقی نمبروں کی نمائندگی میں، سب سے اہم بٹ پر دستخط کیے جاتے ہیں۔ اگر باقی تمام بٹس 0 ہوں تو کیا ہوگا؟ انٹیجرز کے برعکس، جہاں ایسی صورت حال میں نتیجہ ایک منفی نمبر ہوتا ہے جو نمائندگی کی حد کی نچلی حد پر واقع ہوتا ہے، ایک حقیقی عدد جس میں صرف سب سے اہم بٹ 1 پر سیٹ کیا جاتا ہے کا مطلب 0 ہوتا ہے، صرف مائنس کے نشان کے ساتھ۔ اس طرح، ہمارے پاس دو صفر ہیں - +0.0 اور -0.0۔ ایک منطقی سوال پیدا ہوتا ہے: کیا ان نمبروں کو برابر سمجھا جائے؟ ورچوئل مشین بالکل اسی طرح سوچتی ہے۔ تاہم، یہ دو مختلف نمبر ہیں، کیونکہ ان کے ساتھ آپریشن کے نتیجے میں، مختلف اقدار حاصل کی جاتی ہیں:
float f1 = 0.0f/1.0f;
float f2 = 0.0f/-1.0f;
System.out.println("f1="+f1);
System.out.println("f2="+f2);
System.out.println("f1==f2: "+(f1==f2));
float f3 = 1.0f / f1;
float f4 = 1.0f / f2;
System.out.println("f3="+f3);
System.out.println("f4="+f4);
... اور نتیجہ:
f1=0.0
f2=-0.0
f1==f2: true
f3=Infinity
f4=-Infinity
لہذا کچھ معاملات میں +0.0 اور -0.0 کو دو مختلف نمبروں کے طور پر سمجھنا سمجھ میں آتا ہے۔ اور اگر ہمارے پاس دو اشیاء ہیں، جن میں سے ایک میں فیلڈ +0.0 ہے، اور دوسری میں -0.0، تو ان اشیاء کو بھی غیر مساوی قرار دیا جا سکتا ہے۔ سوال یہ پیدا ہوتا ہے کہ آپ کیسے سمجھ سکتے ہیں کہ نمبرز غیر مساوی ہیں اگر ان کا براہ راست موازنہ ورچوئل مشین سے کیا جائے true؟ اس کا جواب یہ ہے۔ اگرچہ ورچوئل مشین ان نمبروں کو برابر سمجھتی ہے، پھر بھی ان کی نمائندگی مختلف ہے۔ لہذا، صرف ایک ہی چیز کی جا سکتی ہے کہ نظریات کا موازنہ کیا جائے. اور اسے حاصل کرنے کے لیے، ایسے طریقے ہیں int Float.floatToIntBits(float)اور long Double.doubleToLongBits(double)، جو شکل میں intاور longبالترتیب تھوڑا سا نمائندگی کرتے ہیں (پچھلی مثال کا تسلسل):
int i1 = Float.floatToIntBits(f1);
int i2 = Float.floatToIntBits(f2);
System.out.println("i1 (+0.0):"+ Integer.toBinaryString(i1));
System.out.println("i2 (-0.0):"+ Integer.toBinaryString(i2));
System.out.println("i1==i2: "+(i1 == i2));
نتیجہ نکلے گا۔
i1 (+0.0):0
i2 (-0.0):10000000000000000000000000000000
i1==i2: false
اس طرح، اگر آپ کے پاس +0.0 اور -0.0 مختلف نمبر ہیں، تو آپ کو حقیقی متغیرات کا ان کی بٹ نمائندگی کے ذریعے موازنہ کرنا چاہیے۔ ایسا لگتا ہے کہ ہم نے +0.0 اور -0.0 کو ترتیب دیا ہے۔ -0.0، تاہم، صرف حیرت کی بات نہیں ہے۔ ایک ایسی چیز بھی ہے جیسے...

NaN قدر

NaNسے مراد Not-a-Number. یہ قدر غلط ریاضیاتی کارروائیوں کے نتیجے میں ظاہر ہوتی ہے، کہتے ہیں، 0.0 کو 0.0 سے تقسیم کرنا، لامحدودیت سے لامحدود، وغیرہ۔ اس قدر کی خاصیت یہ ہے کہ یہ خود کے برابر نہیں ہے۔ وہ.:
float x = 0.0f/0.0f;
System.out.println("x="+x);
System.out.println("x==x: "+(x==x));
نتیجہ نکلے گا...
x=NaN
x==x: false
اشیاء کا موازنہ کرتے وقت یہ کیسے نکل سکتا ہے؟ اگر آبجیکٹ کا فیلڈ برابر ہے NaN، تو موازنہ دے گا false، یعنی اشیاء کو غیر مساوی تصور کرنے کی ضمانت دی جاتی ہے۔ اگرچہ، منطقی طور پر، ہم اس کے بالکل برعکس چاہتے ہیں۔ آپ طریقہ استعمال کرکے مطلوبہ نتیجہ حاصل کرسکتے ہیں Float.isNaN(float)۔ trueاگر دلیل ہے تو یہ واپس آتا ہے NaN۔ اس معاملے میں، میں بٹ کی نمائندگی کا موازنہ کرنے پر انحصار نہیں کروں گا، کیونکہ یہ معیاری نہیں ہے. پرائمیٹوز کے بارے میں شاید اتنا ہی کافی ہے۔ آئیے اب ان باریکیوں کی طرف چلتے ہیں جو ورژن 5.0 کے بعد سے جاوا میں نمودار ہوئی ہیں۔ اور پہلا نکتہ جس پر میں چھونا چاہتا ہوں۔

Java 5.0 ==' کے ذریعے طریقے اور موازنہ پیدا کرنا

ڈیزائن میں ایک نمونہ ہے جسے پیداواری طریقہ کہتے ہیں۔. بعض اوقات اس کا استعمال کنسٹرکٹر کے استعمال سے کہیں زیادہ منافع بخش ہوتا ہے۔ میں آپ کو ایک مثال دیتا ہوں۔ مجھے لگتا ہے کہ میں آبجیکٹ شیل کو اچھی طرح جانتا ہوں Boolean۔ یہ کلاس ناقابل تغیر ہے اور اس میں صرف دو قدریں ہوسکتی ہیں۔ یعنی درحقیقت کسی بھی ضرورت کے لیے صرف دو نسخے ہی کافی ہیں۔ اور اگر آپ انہیں پہلے سے بناتے ہیں اور پھر صرف انہیں واپس کرتے ہیں، تو یہ کنسٹرکٹر کے استعمال سے کہیں زیادہ تیز ہوگا۔ اس طرح کا ایک طریقہ ہے Boolean: valueOf(boolean). یہ ورژن 1.4 میں ظاہر ہوا۔ اسی طرح کے پیداواری طریقے ورژن 5.0 میں Byte, Character, Short, Integerاور کلاسز میں متعارف کرائے گئے تھے Long۔ جب ان کلاسوں کو لوڈ کیا جاتا ہے، تو ان کی مثالوں کی صفیں قدیم اقدار کی مخصوص حدود کے مطابق بنتی ہیں۔ یہ حدود درج ذیل ہیں:
اشیاء کا موازنہ: مشق - 2
اس کا مطلب یہ ہے کہ طریقہ استعمال کرتے وقت، valueOf(...)اگر استدلال مخصوص رینج میں آتا ہے، تو وہی چیز ہمیشہ واپس آ جائے گی۔ شاید اس سے رفتار میں کچھ اضافہ ہوتا ہے۔ لیکن ساتھ ہی مسائل اس نوعیت کے پیدا ہوتے ہیں کہ ان کی تہہ تک پہنچنا کافی مشکل ہو جاتا ہے۔ اس کے بارے میں مزید پڑھیں۔ نظریہ میں، پیداوار کا طریقہ اور کلاس valueOfدونوں میں شامل کیا گیا ہے ۔ ان کی تفصیل بتاتی ہے کہ اگر آپ کو نئی کاپی کی ضرورت نہیں ہے، تو یہ طریقہ استعمال کرنا بہتر ہے، کیونکہ یہ رفتار میں اضافہ دے سکتا ہے، وغیرہ۔ اور اسی طرح. تاہم، موجودہ (جاوا 5.0) کے نفاذ میں، اس طریقہ کار میں ایک نئی مثال بنائی گئی ہے، یعنی اس کے استعمال کی رفتار میں اضافہ کی ضمانت نہیں ہے۔ مزید برآں، میرے لیے یہ تصور کرنا مشکل ہے کہ اس طریقہ کار کو کیسے تیز کیا جا سکتا ہے، کیونکہ اقدار کے تسلسل کی وجہ سے وہاں کیش کو منظم نہیں کیا جا سکتا۔ سوائے عدد کے۔ میرا مطلب ہے، جزوی حصے کے بغیر۔FloatDouble

Java 5.0 آٹو باکسنگ/ان باکسنگ: ' =='، ' >=' اور ' <=' آبجیکٹ ریپرز کے لیے۔

مجھے شبہ ہے کہ پروڈکشن کے طریقے اور مثال کیشے کو انٹیجر پرائمیٹو کے لیے ریپرز میں شامل کیا گیا تھا تاکہ آپریشنز کو بہتر بنایا جا سکے autoboxing/unboxing۔ مجھے آپ کو یاد دلانے دو کہ یہ کیا ہے۔ اگر کسی شے کا کسی آپریشن میں شامل ہونا ضروری ہے، لیکن ایک پرائمیٹو ملوث ہے، تو یہ پرائمیٹو خود بخود کسی شے کے ریپر میں لپیٹ جاتا ہے۔ یہ autoboxing. اور اس کے برعکس - اگر آپریشن میں ایک پرائمیٹو شامل ہونا ضروری ہے، تو آپ وہاں آبجیکٹ شیل کی جگہ لے سکتے ہیں، اور اس سے قدر خود بخود بڑھ جائے گی۔ یہ unboxing. قدرتی طور پر، آپ کو اس طرح کی سہولت کے لئے ادائیگی کرنا پڑے گا. خودکار تبادلوں کی کارروائیاں ایپلیکیشن کو کسی حد تک سست کر دیتی ہیں۔ تاہم، یہ موجودہ موضوع سے متعلق نہیں ہے، لہذا اس سوال کو چھوڑ دیں. سب کچھ ٹھیک ہے جب تک کہ ہم ان کارروائیوں سے نمٹ رہے ہیں جن کا واضح طور پر پرائمیٹوز یا گولے سے تعلق ہے۔ '' آپریشن کا کیا ہوگا ==؟ ہم کہتے ہیں کہ ہمارے پاس دو اشیاء ہیں Integerجن کے اندر ایک ہی قدر ہے۔ وہ کیسے موازنہ کریں گے؟
Integer i1 = new Integer(1);
Integer i2 = new Integer(1);
System.out.println("i1==i2: "+(i1==i2));
نتیجہ:
i1==i2: false

Кто бы сомневался... Сравниваются они How an objectы. А если так:Integer i1 = 1;
Integer i2 = 1;
System.out.println("i1==i2: "+(i1==i2));
نتیجہ:
i1==i2: true
اب یہ زیادہ دلچسپ ہے! اگر autoboxing-e وہی اشیاء واپس کردی جاتی ہیں! یہ وہ جگہ ہے جہاں جال ہے۔ ایک بار جب ہمیں پتہ چل جائے کہ وہی اشیاء واپس آ جاتی ہیں، تو ہم یہ دیکھنے کے لیے تجربہ کرنا شروع کر دیں گے کہ آیا ایسا ہمیشہ ہوتا ہے۔ اور ہم کتنی قدروں کو چیک کریں گے؟ ایک؟ دس؟ ایک سو؟ زیادہ تر امکان ہے کہ ہم اپنے آپ کو ہر سمت میں صفر کے آس پاس سو تک محدود رکھیں گے۔ اور ہمیں ہر جگہ برابری ملتی ہے۔ ایسا لگتا ہے کہ سب کچھ ٹھیک ہے۔ تاہم، تھوڑا پیچھے دیکھو، یہاں . کیا آپ نے اندازہ لگایا ہے کہ کیچ کیا ہے؟... جی ہاں، آٹو باکسنگ کے دوران آبجیکٹ شیلز کی مثالیں پیداواری طریقوں سے بنائی جاتی ہیں۔ یہ مندرجہ ذیل ٹیسٹ سے اچھی طرح سے واضح ہوتا ہے:
public class AutoboxingTest {

    private static final int numbers[] = new int[]{-129,-128,127,128};

    public static void main(String[] args) {
        for (int number : numbers) {
            Integer i1 = number;
            Integer i2 = number;
            System.out.println("number=" + number + ": " + (i1 == i2));
        }
    }
}
نتیجہ اس طرح ہوگا:
number=-129: false
number=-128: true
number=127: true
number=128: false
کیشنگ رینج میں آنے والی اقدار کے لیے ، ایک جیسی اشیاء واپس کی جاتی ہیں، اس سے باہر والوں کے لیے، مختلف اشیاء واپس کی جاتی ہیں۔ اور اس لیے، اگر ایپلی کیشن کے خولوں میں کہیں پرائمیٹوز کے بجائے موازنہ کیا جائے، تو سب سے زیادہ خوفناک غلطی ہونے کا امکان ہے: ایک تیرتا ہوا۔ کیونکہ ممکنہ طور پر کوڈ کو قدروں کی ایک محدود رینج پر بھی جانچا جائے گا جس میں یہ ایرر ظاہر نہیں ہوگا۔ لیکن حقیقی کام میں، یہ یا تو ظاہر ہو گا یا غائب ہو جائے گا، کچھ حسابات کے نتائج پر منحصر ہے۔ ایسی غلطی تلاش کرنے کے مقابلے میں پاگل ہونا آسان ہے۔ لہذا، میں آپ کو مشورہ دوں گا کہ جہاں بھی ممکن ہو آٹو باکسنگ سے گریز کریں۔ اور ایسا نہیں ہے۔ آئیے ریاضی کو یاد رکھیں، 5ویں جماعت سے زیادہ نہیں۔ عدم مساوات A>=Bاور А<=B. تعلقات کے بارے میں کیا کہا جا سکتا ہے Aاور B؟ صرف ایک چیز ہے - وہ برابر ہیں۔ آپ اتفاق کرتے ہیں؟ مجھے لگتا ہے کہ ہاں. آئیے ٹیسٹ چلائیں:
Integer i1 = new Integer(1);
Integer i2 = new Integer(1);
System.out.println("i1>=i2: "+(i1>=i2));
System.out.println("i1<=i2: "+(i1<=i2));
System.out.println("i1==i2: "+(i1==i2));
نتیجہ:
i1>=i2: true
i1<=i2: true
i1==i2: false
اور یہ میرے لیے سب سے بڑی عجیب بات ہے۔ میری سمجھ میں بالکل نہیں آتا کہ اگر یہ خصوصیت اس طرح کے تضادات کو متعارف کراتی ہے تو اسے زبان میں کیوں متعارف کرایا گیا۔ عام طور پر، میں ایک بار پھر دہراؤں گا - اگر اس کے بغیر کرنا ممکن ہے autoboxing/unboxing، تو یہ اس موقع کا بھرپور استعمال کرنے کے قابل ہے۔ آخری موضوع جس پر میں چھونا چاہتا ہوں وہ ہے... Java 5.0. گنتی کے عناصر کا موازنہ (enum قسم) جیسا کہ آپ جانتے ہیں، چونکہ ورژن 5.0 جاوا نے enum - enumeration جیسی ایک قسم متعارف کرائی ہے ۔ اس کی مثالیں بطور ڈیفالٹ کلاس میں مثال کے اعلان میں نام اور ترتیب نمبر پر مشتمل ہوتی ہیں۔ اس کے مطابق، جب اعلان کا حکم تبدیل ہوتا ہے، نمبر بدل جاتے ہیں۔ تاہم، جیسا کہ میں نے مضمون 'Serialization as it is' میں کہا ہے ، اس سے مسائل پیدا نہیں ہوتے ہیں۔ تمام گنتی عناصر ایک ہی کاپی میں موجود ہیں، یہ ورچوئل مشین کی سطح پر کنٹرول کیا جاتا ہے۔ لہذا، ان کا براہ راست موازنہ کیا جا سکتا ہے، لنکس کا استعمال کرتے ہوئے. * * * شاید آج کے لیے آبجیکٹ کے موازنہ کو نافذ کرنے کے عملی پہلو کے بارے میں اتنا ہی ہے۔ شاید میں کچھ یاد کر رہا ہوں۔ ہمیشہ کی طرح، میں آپ کے تبصروں کا منتظر ہوں! ابھی کے لیے، مجھے رخصت لینے دو۔ آپ کی توجہ کے لیے آپ سب کا شکریہ! ماخذ سے لنک: اشیاء کا موازنہ کرنا: مشق
تبصرے
TO VIEW ALL COMMENTS OR TO MAKE A COMMENT,
GO TO FULL VERSION