ایک لطیفہ یہ ہے کہ کمپیوٹر سائنس کمیونٹی کے دو بڑے مسائل ہیں: ایک کیشے باطل ہونے کا مسئلہ ، اور دوسرا نام لینے کا مسئلہ۔ لیکن میرے خیال میں ایک اور بھی مشکل مسئلہ ہے: مساوات کا مسئلہ۔ آپ نے یہ صحیح پڑھا ، مساوی نشان "=" آسان معلوم ہوتا ہے ، لیکن مساوی نشان کا استعمال اور غلط استعمال سافٹ ویئر انجینئرنگ میں بہت سے بڑے مسائل کا سبب ہے۔

اعلان دستبرداری: اس مضمون کو مصنف کریگ اسٹنٹز نے ترجمہ کرنے کا اختیار دیا ہے۔

مصنف | کریگ اسٹنٹز

مترجم | کریسنٹ مون ، انچارج ایڈیٹر | گو روئی

سر تصویری | CSDN بصری چین سے ڈاؤن لوڈ کریں

تیار | CSDN (ID: CSDNnews)

مندرجہ ذیل ترجمہ ہے:

مساوات کا اصول

مجھے یہ بتانے دو کہ پروگرامنگ زبانوں میں غلطی کا شکار مساوات کتنی ہے۔ لیکن پہلے میں یہ سمجھانا چاہتا ہوں کہ مساوات کس طرح نظر آنی چاہئے ، جس کی وضاحت کرنا اصل میں بہت مشکل ہے! جب ہم مساوات کے "کیسے" پر تبادلہ خیال کرتے ہیں تو ، ہمیں یہ اشارہ کرنا چاہئے کہ یہ ایک مخصوص تناظر میں مساوات ہے ، کیونکہ برابری کو قائم کرنے کے بہت سے طریقے ہیں ، اور بہت سے طریقے مختلف سیاق و سباق میں قائم ہیں۔

"ریاضی کا نچوڑ یہ ہے کہ ایک ہی چیز ہمارے سامنے مختلف طریقوں سے پیش کی جاسکتی ہے۔"

——بیری مظہر ، "جب ایک چیز کسی دوسری چیز کے برابر ہے"

قانون

میں نے کہا کہ مختلف سیاق و سباق میں ، مساوات کے مختلف معنی ہوتے ہیں ، لیکن اس کے باوجود ، کچھ چیزیں ہمیشہ درست رہتی ہیں۔ یہ مساوات کا قانون ہے۔

مساوات ایک بائنری آپریشن ہے ، یہ ہے:

• عکاس ، یعنی کسی بھی قیمت کے لئے a = a ہے

• سڈول ، یعنی ، a = b کم کر سکتا ہے b = a ، اور اس کے برعکس

• غیر فعال ، یعنی اگر a = b اور b = c ، تو a = c

پروگرامنگ کی دنیا میں ، ہمیں ایک قانون شامل کرنے کی ضرورت ہے ، کیونکہ بعض اوقات پروگرامر عجیب و غریب حرکتیں کرتے ہیں:

مساوات ہونا ضروری ہے:

• مستقل ، یعنی ، اگر a = b اور a یا b کا کوئی فیلڈ تبدیل نہیں ہوا ہے ، پھر بعد میں دوبارہ جانچ پڑتال کرتے وقت بھی a = b کو درست ہونا چاہئے۔

مذکورہ بالا قوانین آسان نظر آتے ہیں ، لیکن پروگرامنگ کی مقبول زبانیں بھی ایسے آسان قوانین کی پابندی نہیں کرسکتی ہیں۔ لیکن مساوات کا زیادہ سنگین مسئلہ بھی واضح طور پر بیان کرنا مشکل ہے۔

ساختی مساوات

پروگرامنگ زبانوں میں مساوات کے مختلف نفاذ میں ، ایک اہم فرق ساختی مساوات اور حوالہ مساوات ہے۔

ساختی مساوات جانچتی ہے کہ آیا دو حوالہ جات ایک ہی قیمت کے ہیں۔ ایف # ساختی مساوات کو بطور ڈیفالٹ استعمال کرتا ہے:

ٹائپ مائی سٹرنگ = {سوم فیلڈ: سٹرنگ} let a = {سوم فیلڈ = "کچھ ویلیو"} let b = {SomeField = "کچھ ویلیو"} اگر a = b تو // سچائی لوٹ آئے تو ، پھر "پھر" کوڈ بلاک درج کریں

سی # میں یہ معاملہ نہیں ہے ، جو حوالہ مساوات کا استعمال کرتا ہے۔ حوالہ مساوات کا تقاضا ہے کہ دونوں کے مقابلے میں دو چیزیں ایک جیسی ہیں۔ دوسرے لفظوں میں ، اس کا موازنہ کیا جاتا ہے کہ آیا دو متغیرات ایک ہی میموری پتے کی طرف اشارہ کرتے ہیں۔ میموری کے دو مختلف پتے کے حوالوں کو غیر مساوی سمجھا جائے گا ، چاہے ان کی اقدار یکساں ہوں۔

کلاس MyString {نجی پڑھنے کے لئے سٹرنگ کچھ فیلڈ public عوامی سٹرنگ سومفیلڈ {حاصل کریں} عوامی MyString (سٹرنگ سمفیلڈ) = > this.someField = someFeld؛ a var a = new MyString ("کچھ قدر")؛ var b = new MyString ("کچھ قدر")؛ اگر (a == b) false // غلط ، واپسی کوڈ بلاک میں داخل نہیں ہوگی

دوسری زبانیں آپ کو انتخاب کرنے دیں گی۔ مثال کے طور پر ، اسکیم برابری کی جانچ کرتی ہے۔ کوٹلن == ساختی مساوات کے لئے ، === حوالہ مساوات کے لئے (جاوا اسکرپٹ کے == اور === آپریٹرز کے ساتھ الجھن میں نہ پڑیں) ، جاوا اسکرپٹ ایک بالکل الگ چیز ہے۔

مجھے اپنے پروگرام میں ساختی مساوات کا استعمال کب کرنا چاہئے؟ اگر متغیر کی قیمت میں کوئی تغیر نہیں آتا ہے تو پھر ساختی مساوات کو کسی بھی صورتحال میں استعمال کرنا چاہئے! میں جانتا ہوں کہ زیادہ تر پروگرامنگ زبانیں انٹیجرز جیسے اقسام پر ساختی موازنہ استعمال کرتی ہیں۔ جاوا کے علاوہ ، انٹ ٹائپ کو ساختی موازنہ کے لئے استعمال کیا جاتا ہے ، اور انٹیجر ٹائپ ریفرنس موازنہ کے لئے استعمال ہوتا ہے ، جس نے پروگرامرز کی نسلوں کو الجھا دیا ہے۔ ازگر میں بھی اسی طرح کا مسئلہ ہے۔

ساختی موازنہ بھی حوالہ کی قسموں (جیسے اشیاء) کے ل made کیا جانا چاہئے۔ یونٹ ٹیسٹ پر غور کریں جہاں آپ یہ دیکھنا چاہتے ہیں کہ آیا لوٹی ہوئی شے اس قیمت کے برابر ہے جس کی آپ کی توقع ہے۔ ایسی زبانیں جو ساختی مساوات کا استعمال کرتی ہیں ، یہ آپریشن بہت آسان ہے۔

چلو `the حساب کتاب کا نتیجہ متوقع قیمت ہے '' = بتائے جانے کی توقع = {کچھ فیلڈ =" کچھ قدر "Some کچھ اودر فیلڈ = 15 Still پھر بھی دوسری فیلڈ = سچ؛ ...} اصل = حساب کتاب لگائیں۔ آراکیئکل (متوقع ، اصل)

لیکن اگر زبان ساختی مساوات کی حمایت نہیں کرتی ہے ، اور ڈویلپرز کو اپنی ترقی کی ضرورت ہے تو ، انہیں مشکلات کا سامنا کرنا پڑے گا۔

حوالہ مساوات

لیکن جیسا کہ میں نے پہلے کہا ، کچھ حالات میں ساختی مساوات کو استعمال نہیں کرنا چاہئے۔ ایک صورتحال یہ ہے کہ زبان متغیر مواد کی تبدیلیوں کی حمایت کرتی ہے ، اور زیادہ تر پروگرامنگ زبانیں اس کی تائید کرتی ہیں۔ جب کسی متغیر کی قدر بدلی جاتی ہے ، تو یہ کہنا غیر معقول ہے کہ یہ متغیر کسی دوسرے متغیر کے برابر ہے۔ یقینا، ، آپ یہ کہہ سکتے ہیں کہ موازنہ کے وقت یہ دونوں متغیر مساوی ہیں (ساختی طور پر) ، مثال کے طور پر ، یہ اکائی ٹیسٹ کے آخری سطر میں برابر ہیں ، لیکن عام طور پر آپ یہ نہیں مان سکتے کہ یہ دونوں متغیر ایک جیسے ہیں۔ چیز. یہ سمجھنا تھوڑا سا مشکل ہے۔ آئیے ایک مثال کے ساتھ وضاحت کرتا ہوں۔

ہم فرض کرتے ہیں کہ کوئی چیز ایسی ہے جو کسی شخص کی نمائندگی کرتی ہے۔ ساختی مساوات کے ساتھ ایف # میں ، میں لکھ سکتا ہوں:

ٹائپ پرسن = {نام: تار: عمر: عدد؛ اولاد: فرد کی فہرست}

اب میرے دو دوست جین اور سو ہیں ، ان دونوں کا ایک بیٹا جان ہے ، دونوں کی عمر 15 سال ہے۔ وہ مختلف لوگ ہیں ، لیکن ان کے نام اور عمر ایک جیسے ہیں۔ کوئی مسئلہ نہیں!

چلو جین = {نام = "جین"؛ عمر = 47؛ اولاد = } چلو مقدمہ = {نام = "مقدمہ"؛ عمر = 35؛ اولاد = }

یہ بھی اس طرح لکھا جاسکتا ہے:

اجازت دیں = جان = {نام = "جان"؛ عمر = 15 Off اولاد = let؛ بتائیں جین = {نام = "جین"؛ عمر = 47؛ اولاد = } let sue = {نام = "مقدمہ"؛ عمر = 35؛ اولاد = >

کوڈ کے ان دو ٹکڑوں کے افعال بالکل ایک جیسے ہیں۔ میں ان دونوں بیٹوں کی تمیز نہیں کرسکتا ، یہاں تک کہ اگر میں جانتا ہوں کہ وہ الگ الگ لوگ ہیں۔ لیکن یہ کوئی مسئلہ نہیں ہے! اگر مجھے ان میں فرق کرنے کی ضرورت ہو تو ، میں ان کے ڈی این اے کی ہیش جیسی صفات کو شخص کی قسم میں شامل کرسکتا ہوں۔ لیکن اگر مجھے صرف ان کا نام اور عمر جاننے کی ضرورت ہے تو ، اس سے کوئی فرق نہیں پڑتا ہے کہ میں دو چیزوں میں تمیز کرسکتا ہوں ، کیوں کہ اس سے قطع نظر اس سے بھی فرق نہیں پڑتا ہے کہ ان کی اقدار ایک جیسی ہیں۔

فرض کریں جین کے بیٹے کا نام بدل دیا گیا پیٹ۔ ایف # کسی متغیر کی قیمت کو تبدیل کرنے کی حمایت نہیں کرتا ہے ، لہذا مجھے جان (اور جین!) کے لئے ایک نیا شخص مثال بنانے کی ضرورت ہے۔

نیو جین = {نام = "جین"؛ عمر = 47؛ اولاد = }

یہ نیا متغیر والا نیا جین قدرے عجیب لگتا ہے ، لیکن حقیقت میں اس میں کوئی مسئلہ نہیں ہے۔ مندرجہ بالا کوڈ کے ساتھ کوئی مسئلہ نہیں ہے۔ اب اسے C # کے ساتھ آزمائیں۔ C # میں ، متغیرات کو بطور ڈیفالٹ ترمیم کیا جاسکتا ہے:

var جان = نیا شخص ("جان" ، 15 ،) var var jane = new person ("جین" ، 15 ، نئی فہرست < شخص > {جان}) var var مقدمہ = نیا شخص ("مقدمہ" ، 15 ، نئی فہرست < شخص > {جان })؛

یہ کوڈ واضح طور پر غلط ہے: اگر جین کے بیٹے کا نام بدل کر پیٹ کردیا گیا ہے تو ، میں براہ راست حوالہ کردہ قیمت کو تبدیل کرسکتا ہوں۔

jane.Offspring.First.Name = "پیٹ"؛

لیکن مجھے معلوم ہوگا کہ مقدمہ بیٹے نے بھی اپنا نام بدل لیا ہے! لہذا ، یہاں تک کہ اگر دونوں بیٹوں کے ابتدائی نام ایک جیسے ہیں ، تو وہ برابر نہیں ہیں! تو مجھے لکھنا چاہئے:

var jane = new person ("جین" ، 15 ، نئی فہرست < شخص > {نیا شخص ("جان" ، 15 ،)}) var var sue = نیا شخص ("مقدمہ" ، 15 ، نئی فہرست < شخص > {نیا شخص ("جان" ، 15 ،)})؛

اس طرح ، جین اور سو کے بچے برابر نہیں ہیں۔ لہذا ، ان زبانوں میں جو متغیرات کے مواد کو تبدیل کرسکتی ہیں ، حوالہ برابری کو بطور ڈیفالٹ استعمال کرنا مناسب ہے۔

ایک اور صورتحال جہاں ریفرنس مساوات کو استعمال کیا جانا چاہئے پہلے سے جاننا ہے کہ حوالہ مساوات کا نتیجہ وہی ہے جو ساختی مساوات کا ہے۔ واضح طور پر ٹیسٹ ڈھانچے کی مساوات کو اضافی ہیڈ کی ضرورت ہوتی ہے۔ اگر واقعتا آپ کو ساخت کی مساوات کو جانچنے کی ضرورت ہے تو یہ اضافی ہیڈ معمول کی بات ہے۔ تاہم ، اگر آپ بڑی تعداد میں اشیاء تیار کرتے ہیں ، اور پہلے ہی جانتے ہو کہ ہر شے ساختی طور پر غیر مساوی ہے ، تو ضروری نہیں ہے کہ ساختی مساوات کی جانچ کے ل to اضافی ہیڈ خرچ کرنا پڑے ، کیونکہ صرف حوالہ مساوات کے لئے جانچ کرنے سے وہی نتیجہ برآمد ہوسکتا ہے۔

مساوات کی نمائندگی

اصل تعداد میں ، 0.999 ... (لامحدود بار بار چلنے والا اعشاریہ) 1 کے برابر ہے۔ نوٹ کریں کہ یہاں ذکر کردہ "اصلی نمبر" پروگرامنگ زبان میں اصلی قسم کی طرح نہیں ہے۔ ریاضی میں ، اصل تعداد لامحدود ہوتی ہے ، جبکہ پروگرامنگ زبانوں میں حقیقی تعداد محدود ہوتی ہے۔ لہذا ، کوئی پروگرامنگ زبان میں 0.999 ... جیسی کوئی چیز نہیں ہے ، لیکن اس سے کوئی فرق نہیں پڑتا ہے ، آپ 1 کا استعمال کرسکتے ہیں ، ویسے بھی ، دونوں کی قدریں ایک جیسی ہیں۔

اصل شماری کے نظام کی نمائندگی کرتے وقت یہ ریاضی دانوں کے ذریعہ اختیار کردہ بنیادی طور پر ایک انتخاب ہے۔ اگر آپ سسٹم میں کوئی اور چیز شامل کرتے ہیں ، جیسے ایک غیر متناسب تعداد ، تو 0.999 ... اور 1 برابر نہیں ہیں۔

"لیکن اس کا مطلب یہ نہیں ہے کہ اصولوں کو من مانی طور پر طے کیا جاسکتا ہے ، کیونکہ کسی اصول کو قبول کرنے میں ناکامی ناگزیر طور پر عجیب و غریب چیزوں کی ایجاد کرنے کا باعث بنی ہوگی یا ریاضی کے کچھ واقف اصولوں کو ترک کرنا پڑے گا۔"

im ٹائموتھی گورز ، "ریاضی: ایک بہت ہی مختصر تعارف"

اسی طرح ، اصلی نمبر کے نظام میں ، 1/2 اور 2/4 ایک ہی قدر کی نمائندگی کرتے ہیں۔

ان "برابر" کو جاوا اسکرپٹ یا پی ایچ پی میں "غیر سخت" مساوات آپریٹر == کے ساتھ الجھاؤ نہ۔ یہ مساوی وہی نہیں جو ان آپریٹرز ہیں ، اور یہ مساوی اب بھی مساوات کے قانون کی پیروی کرتے ہیں۔ یہ سمجھنا ضروری ہے کہ مختلف طریقوں سے اشیاء کی مساوات کا اظہار کیا جاسکتا ہے۔

IEEE-754 فلوٹنگ پوائنٹ نمبر کے نظام میں ، -0 = 0۔

توجہ اور توسیع

ایک فنکشن دوسرے فنکشن کے برابر کب ہوتا ہے؟ زیادہ تر پروگرامنگ زبانیں مساوات کے حوالوں کا موازنہ کریں گی ، جو میرے خیال میں کوئی مسئلہ نہیں ہے۔ کیونکہ ، افعال کی ساختی تقابل کا کیا فائدہ ہے؟ ہوسکتا ہے کہ ہم افعال کے نفاذ کو چیک کرنے کے ل ref عکاسی کا استعمال کرسکتے ہیں کہ آیا یہ ایک جیسے ہیں؟ لیکن "وہی" کیا کہا جاتا ہے؟ کیا متغیر نام بالکل یکساں ہونگے؟ کیا کوئکسورٹ اور انضمام سے "اسی" فنکشن کو ترتیب دیا جاتا ہے؟

لہذا ، ہم کہتے ہیں کہ جب تک فنکشن ایک ہی ان پٹ (اس کے داخلی عمل درآمد سے قطع نظر) کے ل implementation ایک ہی آؤٹ پٹ کو لوٹاتا ہے تو ، فنکشن توسیع میں برابر ہے ، اور اگر داخلی تعریف یکساں ہے ، تو یہ معنی میں برابر ہے۔ یقینا ، یہ بھی سیاق و سباق پر منحصر ہے۔ ہوسکتا ہے کہ ایک سیاق و سباق میں ، مجھے ایک مستقل وقتی کام کی ضرورت ہے ، دوسرے تناظر میں ، رفتار سے کوئی فرق نہیں پڑتا ہے۔ اہم بات یہ ہے کہ برابری کی وضاحت کرنے کے لئے سیاق و سباق ہونا ضروری ہے اس سے پہلے کہ اسے دو افعال کا موازنہ کرنے کے لئے استعمال کیا جاسکے۔

میں نہیں جانتا کہ اگر کسی زبان نے بھی افعال کا موازنہ کرتے وقت حوالہ مساوات کے علاوہ کوئی اور کوشش کی ہے۔ لیکن یہ جاننا آسان ہے کہ یہ کارآمد ثابت ہوگا! (مثال کے طور پر ، اصلاح کنندہ ڈپلیکیٹ کوڈ وغیرہ کو ختم کرنے کی کوشش کرتا ہے) آپ خود اس کو خود نافذ کرسکتے ہیں ، لیکن مجھے یہ کہنا ہے کہ برابری کی کوئی موازنہ نہیں ہے ، جو مساوات کے غلط تقابل سے بہتر ہے۔

مساوات اور تفویض

پہلے دن سے بطور پروگرامر سیکھا ، نام "برابر" کے دو مختلف تصورات ہیں۔ ایک تفویض ہے ، اور دوسرا مساوات کی جانچ کر رہا ہے۔ جاوا اسکرپٹ میں اس طرح لکھنے کی ضرورت ہے۔

const aValue = someFunction؛ // ویلیو تفویض کریں اگر (aValue === 3) equality // مساوات کا امتحان

دونوں بنیادی طور پر مختلف ہیں۔ موازنہ ایک بولین ویلیو کو لوٹاتا ہے ، جبکہ اظہار پر مبنی زبانوں میں (جیسے روبی) ، اسائنمنٹ تفویض کردہ قیمت لوٹاتا ہے۔

تو روبی کوڈ اس طرح لکھا جاسکتا ہے:

a = b = c = 3

در حقیقت ، 3 متغیر a ، b اور c کے لئے تفویض کیا گیا ہے۔ حوالہ جات کی قسموں پر کوشش نہ کریں ، آپ کو مطلوبہ نتائج نہیں مل سکتے ہیں۔

غیر اظہار پسند زبان میں (جیسے C #) ، تفویض کی قیمت واپس نہیں کرتی ہے۔

ریاضی میں مساوات کے ل for تفویض اور جانچ دونوں مساوات آپریٹر کا استعمال کرتے ہیں۔

اگر aValue = 3 ... جہاں aValue = کچھ فنکشن

(اور ریاضی میں ، کبھی کبھی = دوسرے رشتوں میں بھی استعمال ہوتا ہے ، جیسے معاہدہ (جمع)۔ ریاضی کی دوسری چیزوں کی طرح ، یہاں بھی سیاق و سباق کی تمیز ہونی چاہئے papers جب آپ کاغذات یا کتابیں پڑھتے ہو تو سیاق و سباق پر دھیان دینا ہوگا۔)

جب ریاضی کو دو مختلف کاموں کی ضرورت نہیں ہوتی ہے ، جبکہ پروگرامنگ زبانوں کی ضرورت ہوتی ہے۔ چونکہ ریاضی میں سیاق و سباق کا آسانی سے اندازہ لگایا جاسکتا ہے ، اور تمام زبانوں کو مختلف آپریٹرز کی ضرورت نہیں ہوتی ہے۔ مثال کے طور پر ، F # میں ، تفویض اور مساوات کے لئے ٹیسٹ دونوں ہی استعمال کرتے ہیں =۔ اگرچہ دونوں ایک ہی علامت کا استعمال کرتے ہیں ، لیکن مساوات کے لئے تفویض اور جانچ مکمل طور پر مختلف عمل ہیں۔

aValue = someFunction؛ // اگر تفویض قیمت AValue = 3 تو // مساوات کے ل test جانچیں

گرائمر کا انتخاب جزوی طور پر تاریخی وجوہات پر مبنی ہے: ایف # ایم ایل پر مبنی ہے ، اور ایم ایل ریاضی پر مبنی ہے Java اور جاوا اسکرپٹ کا گرائمر جاوا → C → الگو → فورٹرین پر مبنی ہے۔

فارٹرین کوڈ مرتب کرنے والی مشین کے لئے یہ نحوست ہے کہ وہ نحو کی بنیاد پر دو صورتوں میں فرق کرسکتا ہے ، لہذا مختلف آپریٹرز کا استعمال مناسب ہے۔ لہذا سی زبان اس "خصوصیت" کو ایک نئی سطح پر لے جاتی ہے ، لہذا آپ یہاں تک لکھ سکتے ہیں:

int aValue = someFunction؛ // Assignment if (aValue = 3) {// اسائنمنٹ بھی!

سی زبان کے تجربے کے بغیر لوگوں کو سمجھاؤ: اس کوڈ میں پہلے 3 کے ساتھ aValue کا احاطہ کیا گیا ہے ، اور پھر اس وجہ سے کہ aValue = 3 کے تاثرات کی قدر 3 ہے ، اگر شرط صحیح ہے ، تو if بلاک میں کوڈ پر عمل درآمد جاری رہے گا۔ عام طور پر لکھنے کا یہ طریقہ غلط ہے ، لہذا بہت سارے سی پروگرامر اس غلطی کو پیدا کرنے سے بچنے کے ل if الٹ میں اگر بلاک کی حالت لکھ دیتے ہیں:

int aValue = someFunction؛ // اگر تفویض کردہ قیمت (3 == aValue) equality // مساوات کا امتحان // if (3 = aValue) {// نحو کی غلطی: 3 کو AValue تفویض نہیں کیا جاسکتا۔

مساوات کا استعمال غلط ہے

مذکورہ بالا وضاحت کے ذریعے ، میں امید کرتا ہوں کہ سب سمجھ گئے ہوں گے کہ مساوات آسان نہیں ہے ، اور "درست" احساس تناظر پر منحصر ہے۔ بہر حال ، پروگرامنگ زبانیں اکثر غلط ہونے کے لئے آسان ترین جگہ پاتی ہیں! متعدد بار ، یہ مساوات اور دیگر زبان کی خصوصیات کے امتزاج کی وجہ سے ہوتا ہے ، جیسے مضامین کی تبدیلی۔

عام غلطی: مساوات عکاس نہیں ہے

مساوات کی عکاسی کو یاد کریں ، یعنی کوئی بھی قیمت خود کے برابر ہے ، a = a

.NET میں ، اگر آپ آبجیکٹ کو کہتے ہیں۔ قدر کی نوعیت پر حوالہ جات ایکوولس ، اس کے پیرامیٹرز کو طریقہ کار پر عمل کرنے سے قبل الگ سے پیک کیا جائے گا ، لہذا اگر ایک ہی مثال کو منظور کرلیا گیا تو بھی یہ غلط ثابت ہوگا۔

(دستاویزات سے مثال)

INT1 = 3 Con کنسول.وائٹ لائن (آبجیکٹ۔ ریفرنس ایکولز (انٹ 1 ، انٹ 1))؛ // آؤٹ پٹ جھوٹا

اس کا مطلب یہ ہے کہ a = a ضروری نہیں کہ کسی بھی NET زبان میں سچ ہو ، لہذا عکاسی مطمئن نہیں ہے۔

ایس کیو ایل میں ، یہ اپنے آپ کے برابر نہیں ہے ، لہذا اظہار = (یا اس سے زیادہ امکان کے طور پر ، SOME_EXPPressION = SOME_OTHER_EXPressionION جب دونوں ہوسکتے ہیں) غلط ثابت ہوں گے۔ یہ مندرجہ ذیل گندا بیان کی طرف جاتا ہے:

جہاں (SOME_EXPressionION = SOME_OTHER_EXPPressION) یا (SOME_EXPressionION ہے اور SOME_OTHER_EXPPressION IS) ہے

جو کچھ زیادہ ہونے کا امکان ہے وہ ایک خاص قاعدہ ہے جو ڈویلپرز بھول جائیں گے ، جس کی وجہ سے کیڑے نکل جاتے ہیں۔ کچھ ڈیٹا بیس سرورز کی ایس کیو ایل لینگوئج ڈسسٹنٹ منجانب نہیں ہے ، اور اس کا فنکشن وہ فنکشن ہوتا ہے جس میں اسے ہونا چاہئے۔ (یا میں یہ کہنا چاہئے کہ یہ = نہیں کرتا = کیا کرنا چاہئے؟) ورنہ ، آپ کو مندرجہ بالا مثال میں ایس کیو ایل کا بیان ضرور استعمال کریں۔ زیادہ سے زیادہ حل یہ ہے کہ اجازت نہ ہونے والے کالموں کو زیادہ سے زیادہ استعمال کریں۔

IEEE-754 فلوٹنگ پوائنٹ نمبرز میں ایک ہی مسئلہ ہے ، یعنی NaN! = NaN۔ ایک وضاحت یہ ہے کہ این این غیر یقینی "غیر عدد" نتیجہ کی نمائندگی کرتا ہے ، اور مختلف حساب سے حاصل کردہ این این لازمی طور پر ایک ہی غیر یقینی تعداد میں نہیں ہوتا ہے ، لہذا موازنہ خود غلط ہے۔ مثال کے طور پر ، مربع روٹ (-2) اور انفینٹی / انفینٹی دونوں کے نتائج دونوں نا این ہیں ، لیکن ظاہر ہے کہ وہ ایک جیسے نہیں ہیں! کبھی کبھی ایس کیو ایل کے مسائل بھی اسی طرح بیان کیے جاسکتے ہیں۔ اس کی وجہ سے پیدا ہونے والی پریشانیوں میں سے ایک یہ ہے کہ اصطلاحی الفاظ کے بہت زیادہ معنی ہیں: کیا این اے این اور "نامعلوم" ، یا "غلط قدر" ، یا "گمشدہ قدر" کی نمائندگی کرتا ہے؟

اس طرح کے مسائل کا ایک حل جو عام فلوٹنگ پوائنٹ آپریشن میں نہیں ہوتا یونین کی قسم کا استعمال کرنا ہے۔ اسے F # میں اس طرح لکھا جاسکتا ہے:

ٹائپ میون فلٹ = | فلوٹ آف فلوٹ | اصلی کے غیر حقیقی: فلوٹ * خیالی: فلوٹ | انڈینٹرمینیٹ | /// ...

تب حساب میں صحیح طور پر ان حالات کو سنبھالا جاسکتا ہے۔ اگر آپ کو حساب میں غیر متوقع NaN کا سامنا کرنا پڑتا ہے تو ، آپ استثناء پھینکنے کے لئے سگنلنگ این این کا استعمال کرسکتے ہیں۔

مورچا دو خصوصیات فراہم کرتا ہے ، Eq اور جزوی Eq. حقیقت یہ ہے کہ عق کو لاگو نہیں کیا جاتا ہے اس بات کا اشارہ ہے کہ == آپریٹر عکاس کرنے کی تعمیل نہیں کرتا ہے ، جبکہ روسٹ میں تیرتی نقطہ قسم Eq پر عمل نہیں کرتا ہے۔ لیکن یہاں تک کہ اگر عق کو نافذ نہیں کیا گیا ہے ، تب بھی آپ اپنے کوڈ میں == استعمال کرسکتے ہیں۔ عمل درآمد Eq اشیاء کو ہیش میپ کیز کے بطور استعمال کرسکتا ہے ، جس کی وجہ سے دوسری جگہوں میں طرز عمل میں تبدیلی آسکتی ہے۔

لیکن = اور تیرتے ہوئے نمبروں میں زیادہ سنگین دشواری ہوتی ہے۔

عام غلطیاں: مساوات بھی عین مطابق ہے

میرے خیال میں بہت سے ڈویلپرز آئی ای ای 754 نمبر والے فلوٹنگ پوائنٹ نمبر کے مقابلے کی دشواری سے واقف ہیں ، کیوں کہ زیادہ تر زبانوں میں "فلوٹ" یا "ڈبل" کا نفاذ IEEE-754 ہے۔ 10 * (0.1) 1 کے برابر نہیں ہے ، کیونکہ "0.1" دراصل 0.100000001490116119384765625 ، یا 0.1000000000000000055511151231257827021181583404541015625 کے برابر۔ اگر آپ اس مسئلے میں نئے ہیں تو ، آپ یہ مضمون (https://randomascii.wordpress.com/2012/02/25/comparing-floating- point-numbers-2012-edition/) پڑھ سکتے ہیں ، لیکن یہاں بات یہ ہے کہ ، تیرتے پوائنٹس کی تعداد کا موازنہ کرنے کے لئے == استعمال کرنا مکمل طور پر غیر محفوظ ہے! آپ کو فیصلہ کرنا ہوگا کہ کون سی تعداد اہم ہے ، اور پھر اسی کے مطابق ان کا موازنہ کریں۔

(معاملات کو مزید خراب کرنے کے لئے ، فلوٹنگ پوائنٹ پوائنٹس بہت سی دوسری اقسام کی بنیاد ہیں ، جیسے کچھ زبانوں میں ٹی ڈیٹ ٹائم ٹائپ ، لہذا اگر کچھ مساوات کا موازنہ بھی معقول ہونا چاہئے تو ، وہ صحیح طریقے سے کام نہیں کریں گے۔)

سچل نقطہ نمبروں کا موازنہ کرنے کا صحیح طریقہ یہ ہے کہ آیا وہ "قریب" ہیں ، اور "قریب" مختلف سیاق و سباق میں مختلف معنی رکھتے ہیں۔ یہ آسان نہیں ہے == کیا جا سکتا ہے۔ اگر آپ کو یہ معلوم ہوتا ہے کہ آپ کو اکثر اس قسم کے کام کرنے کی ضرورت ہوتی ہے تو ، پھر آپ کو اعداد و شمار کی دوسری اقسام جیسے فکسڈ پریسنٹی اعشاریے کے استعمال پر غور کرنا چاہئے۔

معاملہ یہ ہے کہ ، پروگرامنگ زبانیں غیر تعاون یافتہ اقسام پر == موازنہ کیوں فراہم کرے؟ در حقیقت ، پروگرامنگ زبانیں ہر قسم کے لئے == مہیا کرتی ہیں ، اور پروگرامرز کو یہ جاننے کے لئے کہ ان میں سے کون سا استعمال نہیں کیا جاسکتا ، اپنے علم پر انحصار کرتے ہیں۔

ایس ایم ایل کے نفاذ کی تفصیل ( کا کہنا ہے کہ:

اس بات کا تعین کریں کہ آیا حقیقت ایک مساوی قسم کی ہے ۔اگر یہ ہے تو ، تو مساوات کا خود ہی معنی بھی قابل اعتراض ہے۔ آئی ای ای ای نے نشاندہی کی کہ مقابلے میں صفر کے اشارے کو نظرانداز کیا جانا چاہئے ، اور جب کوئی پیرامیٹر این این ہے تو ، مساوات کا موازنہ غلط ہونا چاہئے۔ یہ رکاوٹیں ایس ایم ایل پروگرامرز کے لئے بہت پریشان کن ہیں۔ سابقہ ​​کا مطلب یہ ہے کہ 0 = ~ 0 سچ ہے ، اور r / 0 = r / ~ 0 غلط ہے۔ مؤخر الذکر کا مطلب یہ ہے کہ r = r جھوٹی اسامانیتاوں کو واپس کرسکتا ہے ، یا ریف سیل سیل کے لئے ، ایسی صورتحال ہوسکتی ہے جہاں rr = rr سچ ہے لیکن! rr =! rr سچ نہیں ہے۔ ہم صفر کا دستخط شدہ موازنہ قبول کر سکتے ہیں ، لیکن مساوی عکاسی ، مساوی ڈھانچہ ، اور پر غور کریں < > نہیں o = کے ساتھ مساوات کو محفوظ رکھنا چاہئے۔ یہ اضافی پیچیدگیاں ہمیں یہ فیصلہ کرنے پر مجبور کرتی ہیں کہ حقیقت کوئی مساوی قسم کی نہیں ہے۔

اصلی ملکیت = کارروائیوں پر پابندی لگا کر ، ایس ایم ایل ڈویلپرز کو یہ سوچنے پر مجبور کرتی ہے کہ انہیں واقعتا what کس قسم کے موازنہ کی ضرورت ہے۔ میرے خیال میں یہ خصوصیت بہت اچھی ہے!

F # اپنی مرضی کے مطابق اقسام کو نشان زد کرنے کے لئے اوصاف فراہم کرتا ہے جن کو = استعمال نہیں کیا جانا چاہئے۔ بدقسمتی سے ، انہوں نے فلوٹ کو نشان زد نہیں کیا!

عام غلطیاں: غیر مساوی "مساوی"

پی ایچ پی میں دو الگ الگ آپریٹرز ہیں: == اور ===۔ == کے لئے دستاویزات اس کو "مساوی" سے تعبیر کرتی ہیں اور کہا گیا ہے کہ "اگر تبادلوں کے بعد equal a برابر $ b کے برابر ہو تو سچ لوٹائیں"۔ بدقسمتی سے ، اس کا مطلب یہ ہے کہ == آپریٹر ناقابل اعتماد ہے:

< ؟ php var_dump ("608E-4234" == "272E-3063")؛ // سچ ہے؟ >

اگرچہ یہاں موازنہ ایک تار ہے ، پی ایچ پی نے پایا کہ دونوں کو اعداد میں تبدیل کیا جاسکتا ہے ، لہذا تبادلہ کیا گیا۔ چونکہ یہ دونوں تعداد بہت کم ہیں (مثال کے طور پر ، پہلا نمبر 608 * 10 ^ -4234 ہے) ، اور ہم نے پہلے کہا ، تیرتی نقطہ نمبر بہت مشکل ہے۔ دونوں کو فلوٹ (0) میں تبدیل کرنے کے نتیجے میں وہ ایک ہی قیمت پر گول ہوجائیں گے ، لہذا موازنہ صحیح ہوگا۔

نوٹ کریں کہ یہ جاوا اسکرپٹ کے طرز عمل سے مختلف ہے۔ جاوا اسکرپٹ میں بھی ایسا ہی ہے (لیکن ایک جیسا نہیں!) == اور === پی ایچ پی پر آپریٹرز however تاہم ، جاوا اسکرپٹ دونوں فریقوں کو تار سمجھتا ہے اور موازنہ کے نتائج کو غلط ثابت کرے گا۔

خوش قسمتی سے ، پی ایچ پی نے === ("موافق") آپریٹر فراہم کیا ، جو اس معاملے میں صحیح نتیجہ دیتا ہے۔ میں یہ کہنا چاہتا ہوں کہ کبھی بھی استعمال نہ کریں == ، لیکن == اشیاء پر ساختی موازنہ انجام دے گا ، بعض اوقات صرف وہی جو آپ کی ضرورت ہوتی ہے! لہذا میں صرف اتنا ہی کہہ سکتا ہوں کہ == استعمال کرتے وقت آپ کو زیادہ محتاط رہنا ہوگا ، کیونکہ یہ بنیادی اقسام پر صحیح طریقے سے کام نہیں کرے گا۔

عام غلطی: مساوات سڈول نہیں ہے

اگر آپ جاوا میں .equals کو اوورلوڈ کرنا چاہتے ہیں ، تو آپ کو اس بات کا یقین کرنے کے لئے ذمہ دار ہونا چاہئے کہ مساوات کے قانون کی پاسداری ہو!

اگر آپ توجہ نہیں دیتے ہیں تو ، یہ آسانی سے غیر متوازن مساوات کا سبب بنے گا ، یعنی aqueals (b)! = b.equals (a)۔

یہاں تک کہ اگر صورتحال پر غور نہیں کیا گیا ہے (کیونکہ اس سے PointerException کا سبب بنے گا ، اور .equals () ہونے کی اجازت ہے: https://docs.oracle.com/javase/8/docs/api/java/lang/Object.html# برابر - java.lang.Object-)، اگر آپ کو ایک کلاس مل جاتا ہے اور مساویانہ جائزے پر غالب آتے ہیں تو، آپ زیادہ محتاط رہتے!

@ اووررائڈ پبلک بلین برابر (آبجیکٹ o) {اگر (یہ == o) سچے لوٹ آئے if اگر (o ==) جھوٹے لوٹ آئے (اگر (! o.getClass.isAignignFrom (getClass)) // خطرہ! یہ قدم غلط ہے! جھوٹی واپسی؛ یہ کلاس اس کلاس = (یہ کلاس) o؛ // فیلڈ موازنہ // ...)

اگر یہ کلاسک اور ASubtypeOfThisClass دونوں اوورلوڈ. مذکورہ بالا جیسے کوڈ کے ساتھ مساوی ہیں ، تو a.equals (b) b.equals (a) کے برابر نہیں ہوسکتا ہے! صحیح موازنہ ہونا چاہئے:

if (getClass! = o.getClass) غلط لوٹ آئے؛

یہ نہ صرف میری ذاتی رائے ہے بلکہ یہ آبجیکٹ ڈویلپمنٹ معاہدے کی بھی ایک ضرورت ہے (https://docs.oracle.com/javase/8/docs/api/java/lang/Object.html#equals-java.lang. چیز-).

عام غلطی: مساوات عارضی نہیں ہے

یاد رکھیں کہ مساوی موازنہ کے قوانین میں سے ایک یہ ہے کہ اسے عارضی ہونا چاہئے ، یعنی ، اگر a = b اور b = c ، تو a = c۔ بدقسمتی سے ، جب ٹائپ جورجن کے ساتھ مل کر ، بہت سی زبانوں میں یہاں دشواری ہوگی۔

جاوا اسکرپٹ میں ،

'' == 0؛ // true0 == '0'؛ // سچ '' == '0'؛ // غلط!

لہذا جاوا اسکرپٹ میں کبھی بھی == استعمال نہ کریں ، آپ کو === استعمال کرنا چاہئے۔

عام غلطیاں: متضاد مساوات

کوٹلن میں ، == متغیر کی قسم کے مطابق مختلف اقدار واپس کریں گے ، حتی کہ ایک ہی متغیر کے ل for:

تفریح ​​برابر ہے (ایک: فلوٹ ، بی: فلوٹ) {پرنٹلن (a == b)؛ تفریح ​​کے برابرکسی بھی (ایک: کوئی بھی ، بی: کوئی) {پرنٹ لین (a == b)؛ fun main (آرگس: سرنی < سٹرنگ > ) {ویل اے = فلوٹ.نان؛ ویل بی = فلوٹ.نان؛ برابر فلوٹ (ا، بی)؛ برابر (کسی، بی)؛} // پرنٹس جھوٹے ، سچ

یہ زبان کی خصوصیات کا ایک بہت ہی بدقسمت امتزاج ہے اور اس سے بد نظمی برتاؤ ہوسکتا ہے۔

عام غلطی: حوالہ مساوات کا استعمال کریں جہاں ساختی مساوات کو استعمال کیا جانا چاہئے

سی # میں لکھے گئے ایم ایس ٹیسٹ یونٹ کے مندرجہ ذیل ٹیسٹ پر غور کریں:

عوامی باطل حساب کتاب_اس_ درست {متوقع = نیا نتیجہ (SOME_EXPECTED_VALUE)؛ متغیر = اصل میں۔ ڈو کیلکولیشن (SOME_INPUT)؛ Assert.AreEqual (متوقع ، اصل)}

کیا یہ کوڈ صحیح طریقے سے کام کرتا ہے؟ ہم نہیں جانتے! Assert.AreEqual آخر میں آبجیکٹ.ایکوئلز کو کال کرے گا ، جو حوالہ سے مقابلے کی طے شدہ کارکردگی کا مظاہرہ کرے گا۔ جب تک آپ نتائج کو اوورلوڈ نہیں کرتے ہیں۔ ساختی تقابلی کے لئے ایکویلز ، یہ یونٹ ٹیسٹ صحیح طور پر کام نہیں کرے گا۔ آبجیکٹ۔ایکولز کا خیال ہے کہ اگر قسم بدلنے والی ہے ، تو اسے زیادہ بوجھ نہیں ہونا چاہئے۔ یہ عام طور پر معقول ہوتا ہے ، لیکن یونٹ ٹیسٹنگ میں ضروری نہیں ہے۔ (اس کی وجہ یہ ہے. ایکولس () کا موازنہ. گیٹ ہیش کوڈ () سے کیا جانا چاہئے ، اور کسی شے کے ہیش کوڈ کو آبجیکٹ کی زندگی کے دوران تبدیل نہیں ہونا چاہئے۔) نیٹ فریم ورک میں حوالہ کی اقسام کے لئے قریب ترین "گارنٹی ڈھانچے کا موازنہ") "یہ عیاشی ہے < ٹی > ، لیکن Assert.AreEqual استعمال نہیں کیا جاتا ہے ، یہاں تک کہ اگر اس پر عمل درآمد کیا جاتا ہے تو بھی ، استعمال نہیں ہوگا۔

NUnit کے ساتھ صورتحال اور بھی خراب ہے (https://github.com/nunit/nunit/issues/1249)۔

(اس کے برعکس ، جب جاوا کے آبجیکٹ.ہاش کوڈ کو تبدیل کرنے کی اجازت ہے جب شے کا فیلڈ تبدیل ہوجائے گا۔ https://docs.oracle.com/javase/7/docs/api/java/lang/Object.html#hashCode ())

مساوات کا سلوک کیسے کریں

غیر متوقع طور پر ، میں نے = آپریٹر کے بارے میں بہت کچھ لکھا ہے اور اسے ختم نہیں کیا ہے! ٹھیک ہے ، یہ آپریٹر سے بہت آگے ہے۔ یہ اتنا پیچیدہ کیوں ہے؟ بنیادی طور پر دو وجوہات ہیں:

• غیر ضروری پیچیدگی: ہماری پروگرامنگ زبان مساوات کے تقابل کا اچھا کام نہیں کرتی ہے۔ اکثر یہ بالکل بھی کام نہیں کرتا ہے ، اور جب یہ کام نہیں کررہا ہے تو یہ بھی واضح نہیں کرتا ہے ۔مثال کے طور پر ، ساختی موازنہ استعمال کیے جاتے ہیں جہاں حوالہ موازنہ کیا جانا چاہئے۔

• ضروری پیچیدگی: مساوات خود ہی پیچیدہ ہے ، جیسے فلوٹنگ پوائنٹ نمبر کا موازنہ کرنا۔ مقابلے کے افعال جیسے کنارے کے معاملات میں یہ زیادہ پیچیدہ ہے۔

ایک اور تقسیم کا طریقہ "وہ مسائل ہیں جن کو پروگرامنگ لینگویج کے نفاذ کنندہ کے ذریعہ حل کیا جانا چاہئے" ("غیر ضروری پیچیدگی" اوپر) اور "وہ مسائل جنہیں پروگرامنگ زبان کے صارف کو حل کرنا چاہئے"۔

پروگرامنگ کی زبان کو کیا کرنا چاہئے؟

غیر ضروری پیچیدگیوں کے بارے میں ، حیثیت یہ ہے کہ تقریبا ہر مرکزی دھارے کی پروگرامنگ زبان کو مساوات کے احساس کے ساتھ پریشانی کا سامنا کرنا پڑتا ہے۔ یہ "آسان آپریشن جس میں متعدد قوانین پر عمل کرنا چاہئے" بالکل وہی ہے جو پروگرامنگ کی زبان درستگی کو یقینی بنانے کے لئے انحصار کرتا ہے! لیکن میری رائے میں ، صرف ایس ایم ایل ایک ہی وقت میں اصطلاحات اور رن ٹائم / معیاری لائبریری کے معاملے میں قانون کی مساوات کی ضمانت کے بارے میں واقعی سوچتی ہے ، اور ایس ایم ایل بالکل بھی مرکزی دھارے کی زبان نہیں ہے۔

سب سے پہلے ، جہاں مساوات کی موازنہ ممنوع ہے ، پروگرامنگ زبانیں ایسی اقسام تیار کرنا آسان ہونی چاہئیں جو مساوات کا موازنہ نہیں ہونے دیتی ، کیوں کہ یہ کام کرنا آسان ہے اور پیچیدہ ہونے کی ضرورت نہیں ہے (جیسے ایف # میں) ، اور پھر اس خصوصیت کو زیادہ سے زیادہ معیاری لائبریری میں استعمال کرنا چاہئے۔ ، جیسے فلوٹنگ پوائنٹ ٹائپ۔

پروگرامنگ زبان کو ساختی مساوات اور حوالہ مساوات کے مابین واضح طور پر فرق کی نشاندہی کرنا ہوگی۔ ایسے حالات کبھی نہیں ہونے چاہئیں جہاں سلوک غیر یقینی ہو۔ زیادہ تر پروگرامنگ زبانیں == اوورلوڈ ہوں گی ، اور اس کا استعمال حوالہ کی نوعیت کے مطابق ساختی مساوات یا حوالہ مساوات کی نمائندگی کرنے کے لئے کریں گے (زیادہ تر معاملات میں قدر یا حوالہ کے مابین فرق کی بنیاد پر) اس سے ڈویلپرز الجھن میں پڑ جائیں گے۔

کوٹلن صحیح ہونے کے بہت قریب ہے۔ اس کا مطلب === حوالہ کی مساوات اور == مطلب ساختی مساوات ، اگرچہ کسی وجہ سے ، یہ تالیف کی غلطیاں پیدا کرنے کے بجائے قدر کی اقسام کے لئے === کے طور پر سلوک کرتا ہے۔ مقصد ڈویلپر کے الجھن کو کم کرنا چاہئے۔ یہ ڈویلپرز کو یہ سمجھانا چاہتا ہے کہ === اس کا مطلب ہے "حوالہ برابر ہے" ، جتنا ممکن ہو سکے کے برابر نشانات نہیں۔

مجھے نہیں معلوم کہ کون سی دوسری زبانیں جو متغیر کی قیمت کو تبدیل کرنے کی اجازت دیتی ہیں اس سے ساختی مساوات کا انتظام اس انداز میں ہوسکتا ہے جو مبہم نہیں ہے۔ لیکن یہ تصور کرنا آسان ہے کہ مثالی ریاست کیا ہونی چاہئے! دو آپریٹرز تیار کریں ، ایک سنرچناتمک مساوات کے لئے اور دوسرا حوالہ کے برابر کے لئے۔ اس سے متعلقہ آپریٹرز کو صرف اس تناظر میں اجازت دی جاتی ہے کہ پروگرامنگ زبان معقول حد تک مدد دے سکتی ہے۔ مثال کے طور پر ، اگر .NET آبجیکٹ۔ حوالہ جات اور قدر کی اقسام کو لپیٹ نہیں دیا گیا ہے ، اور IEquatable کی طرح ہی استعمال کریں < ٹی > وہ چیز جو کامیابی کو اتنی اجازت دیتا ہے کہ وہ ساختی مساوات کے آپریٹر کو استعمال کرنا چاہے ، تب ڈویلپر آسانی سے پتہ لگاسکتے ہیں کہ کون سا ہے۔

پروگرامرز کیا کریں؟

ہوسکتا ہے کہ اس مضمون کو پڑھنے کے بعد آپ سوچیں گے ، "واہ ، یہ اتنا پیچیدہ ہے! میں اب بھی پروگرام نہیں کرنا چاہتا ، گھر جاؤں اور کھیت جاؤں۔" لیکن اس مضمون کے اتنے لمبے ہونے کی بنیادی وجہ یہ ہے کہ بہت ساری زبانیں غلط ہیں۔ اوپر ہر چیز کو درست کرنے میں کچھ سوچا جاتا ہے ، لیکن یہ اتنا مشکل بھی نہیں ہے۔ کھیتی باڑی سے کہیں زیادہ آسان ہونا چاہئے۔

موجودہ اقسام میں مساوات کا موازنہ کرتے وقت ، اپنے آپ سے پوچھیں:

• کیا یہاں مساوات کا موازنہ کرنا مناسب ہے؟

• اگر یہ معقول ہے تو ، کیا ایک ساختی موازنہ یا حوالہ موازنہ کیا جانا چاہئے؟

• اسی موازنہ کے طریقہ کار کے لئے ، میری پروگرامنگ زبان کس طرح کی مدد فراہم کرتی ہے؟

• کیا میں اس موازنہ کے طریقہ کار کے نفاذ کے لئے پروگرامنگ زبان کو صحیح استعمال کرتا ہوں؟

اپنی مرضی کے مطابق قسم کے ڈیزائن کرتے وقت آپ بھی اسی طرح کے سوالات پوچھ سکتے ہیں۔

• کیا میری قسم مساوات کے مقابلے کی حمایت کرے؟ پھر بھی زیادہ پیچیدہ موازنہ کی ضرورت ہے ، جیسے فلوٹ؟

• کیا میری قسم بدلنے والی ہو؟ اس سے مساوات پر کیا اثر پڑتا ہے؟

• کیا حوالہ کے مقابلے کی حمایت کی جانی چاہئے؟ یا ساختی موازنہ؟ کیا ہمیں دونوں کی حمایت کرنی چاہئے؟

اگر آپ کی قسم بدلی جاسکتی ہے تو ، آپ کو اسے بدلنے پر تبدیل کرنے پر غور کرنا چاہئے۔ یہ تب بھی حاصل کیا جا سکتا ہے یہاں تک کہ اگر زبان بذریعہ ڈیفالٹ ہو! مساوات کے تقابل کے معاملے میں بہت سے فوائد کے علاوہ ، غیر متزلزل فن تعمیر کے بہت سے دوسرے فوائد ہیں۔ بدلاؤ والے ڈیٹا ڈھانچے کے ساتھ C # روزلن مرتب ایک بہت عمدہ مثال ہے۔

نحو کے درخت کی تیسری خاصیت یہ ہے کہ وہ ناقابل تبدیلی اور دھاگے سے محفوظ ہیں۔ اس کا مطلب یہ ہے کہ درخت کے حصول کے بعد ، یہ موجودہ کوڈ حالت کا سنیپ شاٹ ہے ، اور یہ کبھی تبدیل نہیں ہوگا۔ اس طرح ، متعدد صارفین ڈیڈ لاک یا نقل کی فکر کیے بغیر مختلف موضوعات میں ایک ہی نحو کے درخت کے ساتھ بیک وقت کام کرسکتے ہیں۔ چونکہ درخت ناقابل تبدیلی ہے ، اور درخت میں کوئی براہ راست تبدیلیاں نہیں لائی جاسکتی ہیں ، لہذا نحوی درخت کو بنانے اور ان میں ترمیم کرنے کا ذمہ دار فیکٹری طریقہ درخت کا نیا سنیپ شاٹ تشکیل دیتا ہے۔ درخت خود ہی بہت موثر ہے ، کیوں کہ یہ بنیادی نوڈس کو دوبارہ استعمال کرتا ہے ، لہذا ایک نئے ورژن کی تشکیل تیز ہے ، اور صرف تھوڑی بہت میموری کی ضرورت ہے۔

Comp.NET کمپائلر پلیٹ فارم SDK دستاویزات

اصل: https://www.craigstuntz.com/posts/2020-03-09-equality-is-hard.html

programming جدید پروگرامنگ زبان PK ، سات پروگرامنگ زبانیں جن کا ڈویلپرز 2020 میں خیال رکھتے ہیں!

y مائی ایس کیو ایل نے اوریکل کو سلم اور سب سے پہلے نمبر پر ہے ، نجی کلاؤڈ سب سے زیادہ استعمال ہوا ہے ، اور اعداد و شمار کی بڑی صلاحیتیں کم ہیں! | چین بگ ڈیٹا ایپلیکیشن کی سالانہ رپورٹ

Gob گوبانگ کا الفاگو ورژن چلانے کے لئے CNN کا استعمال کیسے کریں؟

program پروگرامر جو مچھلی پکڑتا تھا ، اب وہہان میں اوور ٹائم کام کرنے کے لئے رضاکار ہیں

blockکیا بلاکچین اور بڑا ڈیٹا مل کر ڈیٹا کی سالمیت کے ایک نئے دور کا آغاز کرسکتا ہے؟

-یہ 2.0 ، شارڈنگ ، ڈی اے جی ، آف چین اسٹیٹ چینل ... بلاکچین اسکیل ایبلٹی کے حل کا جائزہ!