'<' বনাম '! =' শর্ত হিসাবে 'লুপের জন্য'?

Question

বলুন আপনার নীচের forলুপটি রয়েছে:

for (int i = 0; i < 10; ++i) {
    // ...
}

এটি সাধারণত এটিও লেখা যেতে পারে:

for (int i = 0; i != 10; ++i) {
    // ...
}

শেষের ফলাফলগুলি একই, সুতরাং অন্যগুলির ব্যবহারের জন্য কোনও বাস্তব যুক্তি আছে কি? ব্যক্তিগতভাবে আমি প্রাক্তনটি iকোনও কারণে হাইওয়াইরে যায় এবং মান 10 এড়িয়ে যায়।

_{* যাদু সংখ্যার ব্যবহারকে ক্ষমা করুন, তবে এটি কেবল একটি উদাহরণ।}

Comments

এর int i = 10; while(i --> 0) { /* stuff */ }

— যেকোনটিরও

@glowcoder তীর অপারেটর আমার প্রিয়

— কারসন মায়ার্স

@ ব্লককোডার, দুর্দান্ত তবে এটি পিছন থেকে সরে গেছে। আপনি সবসময় এটি চাইবেন না।

@ সুপার ইলেক্ট্রিক, এটি পার্স করেছেwhile ((i--) > 0)

— ক্রিস্টোফার জনসন

সেন্সর ইনপুট হওয়ার জন্য কিছুক্ষণ লুপ পরীক্ষার ফলে ঘটে যাওয়া শিল্প দুর্ঘটনার বিষয়ে একটি (সম্ভবত অ্যাপোক্রিফাল) গল্প রয়েছে! = MAX_TEMP। দুর্ভাগ্যক্রমে একদিন সেন্সর ইনপুট MAX_TEMP এর চেয়ে কম হয়ে MAX_TEMP এর চেয়ে বেশি হয়ে MAX_TEMP ছাড়িয়ে চলেছে। প্রক্রিয়াটি সনাক্ত না করে অতিরিক্ত উত্তপ্ত হয়ে যায় এবং আগুনের সূত্রপাত হয়। কখনও কখনও! = এবং <এর মধ্যে পার্থক্য থাকে।

— চার্লস ই। গ্রান্ট

Answer 1

এক বা অন্যটিকে বেছে নেওয়ার কারণ হ'ল উদ্দেশ্য এবং এর ফলস্বরূপ, এটি পঠনযোগ্যতা বাড়ে ।

অভিপ্রায়: লুপটি i10 টির চেয়ে কম 10 মিনিটের জন্য চালানো উচিত , যতক্ষণ iনা 10 এর সমান হয় না, ততক্ষণ এই বিশেষ ক্ষেত্রে যদি উত্তরটি একই রকম হয়, তবে এটি আপনার অর্থটি নয়, তাই এটি হওয়া উচিত নয় যে মত লেখা।

পঠনযোগ্যতা: আপনি কী বোঝাতে চেয়েছেন তা লেখার ফলাফল এটি বোঝাও সহজ also উদাহরণস্বরূপ, যদি আপনি ব্যবহার করেন i != 10তবে কোডটি পড়ে কেউ ভাবতে পারে যে লুপের ভিতরে কোনও উপায়ে i10 এর চেয়ে বড় হতে পারে এবং লুপটি চালিয়ে যাওয়া উচিত (বিটিডব্লু: এটির শিরোনাম ছাড়া অন্য কোথাও পুনরুক্তিকারীদের সাথে গোলযোগ করা খারাপ স্টাইল bad for-statement, কিন্তু যে মানে মানুষ এটা কাজ করে না না এবং এর ফলে রক্ষণাবেক্ষণকারীকে এটা আশা)।

Comments

না, লুপটি i"10 এর চেয়ে ছোট" হিসাবে চালানো উচিত নয় , যতক্ষণ না (এই ক্ষেত্রে) উপরের সীমাটি না পৌঁছানো হয় ততক্ষণ এটি চালানো উচিত। সি ++ ব্যবধান / পুনরুক্তিকারীর পরিসীমা যুক্তিপূর্ণ ব্যবহার করার সময়, এটা মাধ্যমে এই প্রকাশ করার অনেক বেশী যৌক্তিক এর !=চেয়ে <।

— কনরাড রুডল্ফ

@ কনরাড আমি এর সাথে মোটেই একমত নই। মূল বিষয়টি কৌতূহলযুক্ত নয়, বরং সেই কনস্ট্রাক্টটি বেছে নেওয়া যা শর্তের অভিপ্রায়টি সর্বোত্তমভাবে প্রকাশ করে। এবং তাই, যদি আপনি 0 থেকে শুরু করে উপরে চলে যাওয়া কোনও কিছু দিয়ে লুপ পছন্দ করেন, তবে <প্রকৃতপক্ষে এটি স্পষ্টভাবে প্রকাশ করে।

— ডেকার্ড

@ কনরাড, আপনি পয়েন্টটি মিস করছেন। এই লুপের ইনক্রিমেন্ট অপারেটর এটি স্পষ্ট করে তোলে যে লুপ শর্তটি একটি উচ্চতর বাউন্ড, কোনও পরিচয় তুলনা নয়। যদি আপনি হ্রাস করছিলেন তবে এটি একটি নিম্ন সীমা হতে হবে। যদি আপনি কোনও অ-অর্ডারযুক্ত সংগ্রহের মাধ্যমে পুনরাবৃত্তি করেন তবে পরিচয়টি সঠিক অবস্থা হতে পারে।

— অ্যালেক্স ফেনম্যান

@ অ্যালেক্স ইনক্রিমেন্ট আমার বক্তব্য ছিল না। একটি বিরতি এমনকি অগত্যা না আছে একটি আদেশ। এটি কেবল পুনরাবৃত্তি করে ... ভাল, কিছু শেষ না হওয়া পর্যন্ত। উদাহরণস্বরূপ, একটি হ্যাশ সেটের উপাদানগুলি। সি ++ এ এটি forপুনরাবৃত্তকারী এবং একটি লুপ ব্যবহার করে করা হয় । <এখানে ব্যবহার নিরীহ হবে। এছাড়াও, ডেকার্ড মনে হয় এটি স্বীকার করে। আমি আমার প্রতিক্রিয়াতে তার মন্তব্যে খুব সম্মত।

— কনরাড রুডল্ফ

মনে রাখবেন, যদি আপনি মৃগয়া পয়েন্টার সঙ্গে একটি ঘূর্ণমান বাফার ব্যবহার করেন, আপনি ব্যবহার করা আবশ্যক!=

— সান ফ্রান্সিসকো।

Answer 2

<প্যাটার্ন সাধারণত ব্যবহারযোগ্য এমনকি যদি বৃদ্ধি 1 ঠিক হবে না ঘটে থাকে।

এটি প্রকৃতপক্ষে কীভাবে করা হয় তা নির্বিশেষে লুপগুলি করার একক সাধারণ উপায়কে মঞ্জুরি দেয়।

Comments

এটি iপ্রয়োজনে সম্পূর্ণরূপে নিরাপদে লুপের অভ্যন্তরে সংশোধন করার অনুমতি দেয় ।

— ম্যাথু শার্লে

অথবা যদি 'i' সম্পূর্ণরূপে অনিরাপদভাবে পরিবর্তিত হয় ... অন্য একটি দলে একটি অদ্ভুত সার্ভার সমস্যা ছিল। এটি 100% সিপিইউ ব্যবহারের প্রতিবেদন করে চলেছে এবং এটি সার্ভার বা মনিটরিং সিস্টেমের সাথে সমস্যা হতে হবে, তাই না? না, আমি 'বিশেষজ্ঞ সিনিয়র প্রোগ্রামার' লিখেছিলাম এমন লুপ শর্তটি পেয়েছি যা একই সমস্যার সাথে আমরা কথা বলছি with

— jqa

লুপগুলির জন্য সমস্ত সি ++ ব্যবহার করা যায় না <, যেমন ক্রমানুসারে পুনরাবৃত্তির মতো এবং !=এটি সি ++ এ লুপগুলি করার একক সাধারণ উপায়।

— ডেভিড থর্নলি

@ স্নোফারস: আমি এই মন্তব্যে যথেষ্ট পার্সিং করছি না। খুব বেশি পরিমাণে পুনরুক্তি বাড়ানোর ক্ষেত্রে আপনি নির্ভরযোগ্যভাবে ব্যতিক্রম পাবেন না (যদিও আরও নির্দিষ্ট পরিস্থিতি রয়েছে যেখানে আপনি যাবেন)।

— ডেভিড থর্নলি

ওয়েল, আমি অনুসরণ <প্যাটার্ন কারণ এটি পরিবর্তে এক কীস্ট্রোক দুটি প্রয়োজন >প্যাটার্ন, এবং চার দিয়ে !=। এটি সত্যই ওসিডির মতো দক্ষতার বিষয়।

— স্পোকাইক

Answer 3

সি ++ এ স্কট মায়ার্স আরও কার্যকর সি ++ (আইটেম 6) এর সুপারিশটি সর্বদা দ্বিতীয়টি ব্যবহার করা উচিত যদি না আপনার কারণ না থাকে তবে এর অর্থ হ'ল পুনরাবৃত্তিকারী এবং পূর্ণসংখ্যার সূচকগুলির জন্য আপনার একই বাক্য গঠন রয়েছে যাতে আপনি intবিভাজক এবং পুনরাবৃত্তির মধ্যে নির্বিঘ্নে অদলবদল করতে পারেন সিনট্যাক্সে কোনও পরিবর্তন ছাড়াই।

অন্যান্য ভাষায় এটি প্রযোজ্য না তাই আমার ধারণা <থোরবজর্ন রাভন অ্যান্ডারসেনের বক্তব্যটির কারণে সম্ভবত এটি পছন্দনীয়।

যাইহোক, অন্য দিন আমি অন্য বিকাশকারীর সাথে এটি নিয়ে আলোচনা করছিলাম এবং তিনি বলেছিলেন যে <বেশি পছন্দ করার !=কারণ হ'ল iদুর্ঘটনাক্রমে একাধিকজন বৃদ্ধি পেতে পারে এবং এর ফলে ব্রেক শর্তটি পূরণ না হওয়ার কারণ হতে পারে; এটি আইএমও হ'ল বোকা বোঝা।

Comments

"বাজে বোঝার বোঝা" ... যতক্ষণ না আপনি স্বীকৃতভাবে লুপটির শরীরে অতিরিক্ত আই ++ রাখবেন।

+1, বিশেষত "বাজে বোঝার লোড" এর জন্য, কারণ এটি। যদি লুপ বডিটি দুর্ঘটনাক্রমে কাউন্টারটিকে বাড়িয়ে তোলে তবে আপনার অনেক বড় সমস্যা রয়েছে।

— কনরাড রুডল্ফ

@ বি টাইলার, আমরা কেবল মানুষ এবং এর আগে আরও বড় ভুল হয়েছিল। <তার চেয়ে বেশি ডিফেন্সিভ প্রোগ্রামিং হিসাবে বিবেচনা করুন !=...

@ থরবজর্ন রাভন অ্যান্ডারসন - আমি বলছি না যে আমি আপনার সাথে একমত নই, আমি করি; <আমি আরও রক্ষণাত্মক এবং আমার সহকর্মীরা এটি ঘৃণা করে যদি আমি লিখি তবে আমি এটি লিখি !=না। যাইহোক, !=সি ++ এর ক্ষেত্রে একটি মামলা রয়েছে এবং এটি আমি উপস্থাপন করেছি।

একটি দৃশ্যে যেখানে দুর্ঘটনাজনিত অতিরিক্ত দিয়ে শেষ করা যায় i++সেটি হল লুপের জন্য যখন কিছুক্ষণ লুপ পরিবর্তন করা হয়। নিশ্চিত নয় যে পুনরাবৃত্তির অর্ধেক সংখ্যা হ'ল যদিও (কাছাকাছি) অসীম লুপের চেয়ে ভাল; দ্বিতীয়টি সম্ভবত বাগটিকে আরও সুস্পষ্ট করে তুলবে।

— ak2

Answer 4

(I <10) ব্যবহার করা আমার মতে একটি নিরাপদ অনুশীলন। এটি সম্ভাব্য ছাড়ার ক্ষেত্রে সর্বাধিক সংখ্যক কেস নিয়েছে - যা 10 বা এর চেয়ে বড় বা সমান সব কিছু এটি অন্য ক্ষেত্রে (i! = 10) এর সাথে আলাদা করুন; এটি কেবলমাত্র একটি সম্ভাব্য ছাড়ার কেস ধরেছে - যখন আমি ঠিক 10 হয়।

এর একটি উপজাত এটি পাঠযোগ্যতা উন্নত করে। অতিরিক্তভাবে, যদি বর্ধিততাটি অন্য 1 টির মতো হয় তবে এটি ছাড়ার কেসটি লেখার সময় আমাদের কোনও ভুল হওয়া উচিত সমস্যার সম্ভাবনা হ্রাস করতে সহায়তা করে।

বিবেচনা:

1) for (i = 1; i < 14; i+=2)

2) for (i = 1; i != 14; i+=2)

যদিও উভয় ক্ষেত্রেই ত্রুটিযুক্ত / ভুল হতে পারে, দ্বিতীয়টি সম্ভবত আরও ভুল হতে পারে কারণ এটি ছাড়বে না। প্রথম কেসটি প্রস্থান করবে, এবং উচ্চতর সম্ভাবনা রয়েছে যে এটি সঠিক স্থানে ছেড়ে যাবে, যদিও 14 সম্ভবত ভুল সংখ্যা (15 সম্ভবত ভাল হবে)।

Comments

প্রথম মামলাটি ঠিক হতে পারে! যদি আপনি 14 এর চেয়ে কম সমস্ত প্রাকৃতিক সংখ্যার উপরে পুনরাবৃত্তি করতে চান, তবে তা প্রকাশ করার জন্য এর চেয়ে ভাল আর কোনও উপায় নেই - "যথাযথ" উপরের আবদ্ধ (13) গণনা করা সরল বোকামি হবে।

— মার্টিনাস

Answer 5

এখানে আরও একটি উত্তর দেওয়া হয়েছে যা এখনও কেউ মনে করেনি। forলুপগুলি যখন ব্যবহার করা উচিত যখন আপনি একটি ক্রম উপর পুনরাবৃত্তি প্রয়োজন । !=লুপের জন্য সমাপ্তির শর্তটি উল্লেখ করার সর্বাধিক সংক্ষিপ্ত পদ্ধতিটি ব্যবহার করা Using তবে, কম সীমাবদ্ধ অপারেটর ব্যবহার করা একটি খুব সাধারণ ডিফেন্সিভ প্রোগ্রামিং আইডিয়াম om পূর্ণসংখ্যার ক্ষেত্রে এটি কোনও ব্যাপার নয় - এটি একটি আরও নির্দিষ্ট উদাহরণ ছাড়া কেবল একটি ব্যক্তিগত পছন্দ। !=অন্যরা যে কারণে বলেছে সে কারণে আপনি পুনরাবৃত্তকারীদের সাথে সংগ্রহের উপরে লুপিং । আপনি যদি floatবা এর ক্রমগুলি বিবেচনা করেন doubleতবে আপনি যে কোনও !=মূল্যে এড়াতে চান ।

আমি যেটা উল্লেখ করতে চেয়েছিলাম তা হ'ল এটি forযখন ব্যবহৃত হয় যখন আপনাকে কোনও অনুক্রমের উপর পুনরাবৃত্তি করতে হবে। উত্পন্ন ক্রমের একটি প্রারম্ভিক বিন্দু, একটি বিরতি এবং একটি সমাপ্তি শর্ত রয়েছে। এগুলি forবিবৃতিতে সংক্ষিপ্তভাবে নির্দিষ্ট করা হয় । আপনি যদি নিজেকে খুঁজে পান (1) এর পদক্ষেপের অংশটি অন্তর্ভুক্ত না করে forবা (2) trueগার্ডের শর্ত হিসাবে কিছু নির্দিষ্ট করে , তবে আপনার কোনও forলুপ ব্যবহার করা উচিত নয় !

whileলুপ প্রক্রিয়াকরণ অব্যাহত রাখার জন্য যখন একটি নির্দিষ্ট শর্ত পূরণ করা হয় ব্যবহার করা হয়। আপনি যদি সিকোয়েন্সটি প্রক্রিয়াজাত না করে থাকেন তবে সম্ভবত whileপরিবর্তে আপনি একটি লুপ চান । গার্ড শর্তের যুক্তিগুলি এখানে একই রকম, তবে একটি whileএবং forলুপের মধ্যে সিদ্ধান্তটি খুব সচেতন হওয়া উচিত। whileলুপ আইএমও সি ++ চেনাশোনার মধ্যে কম প্রশংসা।

আপনি যদি আইটেমগুলির সংগ্রহের প্রক্রিয়াজাতকরণ করছেন (খুব সাধারণ- forলুপ ব্যবহার), তবে আপনার সত্যিকার অর্থে আরও একটি বিশেষ পদ্ধতি ব্যবহার করা উচিত। দুর্ভাগ্যক্রমে, std::for_eachবেশ কয়েকটি কারণে সি ++ এ বেশ বেদনাদায়ক। অনেক ক্ষেত্রে forফ্রি-স্ট্যান্ডিং ফাংশনে একটি লুপের শরীরকে পৃথক করা (কিছুটা বেদনাদায়ক হয়ে থাকে) এর ফলে অনেকগুলি পরিষ্কার সমাধান হয়। যখন সংগ্রহের সঙ্গে কাজ, বিবেচনা std::for_each, std::transformঅথবা std::accumulate। অনেক অ্যালগরিদমের বাস্তবায়ন সংক্ষিপ্ত এবং স্ফটিক পরিষ্কার হয়ে যায় যখন এই উপায়ে প্রকাশ করা হয়। লুপের শরীরকে পৃথক ফাংশন / পদ্ধতিতে বিচ্ছিন্ন করা আপনাকে অ্যালগরিদম, তার ইনপুট প্রয়োজনীয়তা এবং ফলাফলগুলিতে মনোনিবেশ করতে বাধ্য করে।

আপনি যদি জাভা, পাইথন, রুবি বা এমনকি সি ++ 0 এক্স ব্যবহার করছেন তবে আপনার সঠিক সংগ্রহের অগ্রভাগ লুপ ব্যবহার করা উচিত । সি ++ কম্পাইলাররা এই বৈশিষ্ট্যটি বাস্তবায়িত করার সাথে সাথে এই forধরণের আলোচনার মতো অনেকগুলি লুপ অদৃশ্য হয়ে যাবে।

Comments

"তবে, কম সীমাবদ্ধ অপারেটর ব্যবহার করা একটি খুব সাধারণ ডিফেন্সিভ প্রোগ্রামিং আইডিয়াম।" এটি কমবেশি যোগ করে দেয়।

— জেমস পি।

তুলনায় সঙ্গে অভিপ্রায় পার্থক্য discussin জন্য +1 while, forএবং foreach(অথবা ভাষা equivilant)

— কেভিন Peno

কঠোরভাবে বলতে, লুপ প্রক্রিয়াকরণ অব্যাহত রাখার জন্য ব্যবহার করা হয় না হওয়া পর্যন্ত একটি নির্দিষ্ট অবস্থা না পূরণwhile

— ঊষা

@ অলনিটক - দোহ ... আমি এটি ঠিক করব :)

— ডি.শ্যাওলি

"কম সীমাবদ্ধ" এর দুটি সম্ভাব্য অর্থ দ্বারা আমি বিভ্রান্ত হয়ে পড়েছিলাম: এটি অপারেটরটিকে যে মানগুলি ( <) দিয়ে যায় তার ক্ষেত্রে হালকা হওয়া বা অপারেটর যে মানগুলিতে ব্যর্থ হয় ( !=) এটির ক্ষেত্রে হালকা হতে পারে refer

— মতিন উলহাক

Answer 6

"কম" ব্যবহার করা শব্দার্থগতভাবে সঠিক, আপনি সত্যিকার অর্থেই গণনা অবধি i10 এর চেয়ে কম নন, সুতরাং "এর চেয়ে কম" আপনার উদ্দেশ্য পরিষ্কারভাবে প্রকাশ করে। "সমান নয়" ব্যবহারটি স্পষ্টতই কার্যত কল ক্ষেত্রে কাজ করে, তবে কিছুটা আলাদা অর্থ বোঝায়। কিছু ক্ষেত্রে আপনার প্রয়োজন অনুসারে এটি হতে পারে তবে আমার অভিজ্ঞতায় এটি কখনও হয়নি। যদি আপনার সত্যিই যদি এমন কোনও ঘটনা ঘটে থাকে যেখানে i10 এর চেয়ে কম বা কম হতে পারে তবে আপনি 10 এর সমান না হওয়া পর্যন্ত লুপিং রাখতে চান, তবে সেই কোডটির জন্য খুব স্পষ্টভাবে মন্তব্য করা দরকার ছিল, এবং সম্ভবত আরও কিছু রচনা দিয়ে আরও ভাল লেখা যেতে পারে, যেমন whileসম্ভবত একটি লুপ হিসাবে ।

Answer 7

আমি less thanওভার ওভারের পক্ষে হওয়ার একটি কারণ not equalsহ'ল গার্ড হিসাবে কাজ করা। কিছু সীমিত পরিস্থিতিতে (খারাপ প্রোগ্রামিং বা স্যানিটাইজেশন) not equalsএড়িয়ে যেতে পারে যেখানে less thanএখনও কার্যকর হবে।

এখানে একটি উদাহরণ যেখানে স্যানিটাইজেশন চেকের অভাবে অদ্ভুত ফলাফলের দিকে পরিচালিত করেছে: http://www.michaeleisen.org/blog/?p=358

Answer 8

আপনি <তার চেয়ে বরং ব্যবহার পছন্দ করতে পারেন তার একটি কারণ এখানে !=। আপনি যদি এমন কোনও ভাষা ব্যবহার করছেন যার গ্লোবাল ভেরিয়েবল স্কোপিং রয়েছে তবে অন্যান্য কোড সংশোধিত হলে কী হবে i? আপনি যদি এর <পরিবর্তে ব্যবহার করছেন !=তবে সবচেয়ে খারাপটি ঘটে যা হ'ল পুনরাবৃত্তিটি দ্রুত শেষ হয়: সম্ভবত iদুর্ঘটনার কারণে অন্য কোনও কোড বর্ধিত হয় এবং আপনি লুপের জন্য কয়েকটি পুনরাবৃত্তি বাদ দেন। তবে আপনি যদি 0 থেকে 10 এর মধ্যে লুপ করছেন এবং লুপটি 9 এ চলে যায় এবং iকোনও অদ্ভুত কারণে কিছু খারাপভাবে লিখিত থ্রেড বৃদ্ধি হয় তবে কী হয় । তারপরে আপনার লুপটি সেই পুনরাবৃত্তি এবং বৃদ্ধিগুলি শেষ করে iযাতে মান এখন ১১ হয় 11. লুপটি প্রস্থান শর্তটি এড়িয়ে যায় ( iকখনই 10 এর সমান হয় না) এটি এখন অসীমভাবে লুপ করবে op

এটি অগত্যা বিশেষত অদ্ভুত থ্রেডিং-এবং-গ্লোবাল-ভেরিয়েবল টাইপ যুক্তিযুক্ত হওয়া উচিত নয় যা এর কারণ হয়। এটি কেবল এমন হতে পারে যে আপনি একটি লুপ লিখেছেন যা ব্যাকট্র্যাকের প্রয়োজন। যদি আপনি লুপটির iঅভ্যন্তরে পরিবর্তন ঘটাচ্ছেন এবং আপনি আপনার যুক্তিটি স্ক্রু আপ করেছেন, এটি থাকার কারণে এটির চেয়ে একটি উচ্চতর আবদ্ধ !=থাকে তবে আপনাকে অসীম লুপে ফেলে যাওয়ার সম্ভাবনা কম থাকে।

Comments

অবশ্যই, এটি প্রতিটি লুপের জন্য একটি নিখুঁত যুক্তি এবং সাধারণভাবে আরও কার্যকরী প্রোগ্রামিং শৈলীর মতো বলে মনে হয়। তবে, যখন পরিবর্তনীয় ভেরিয়েবলগুলি এত বেশি মজাদার হয় তখন আপনি কেন এটি করতে চান ?!

— টম মরিস

আমি মনে করি না যে এটি অত্যন্ত মারাত্মক কারণ। যে কোনও উপায়ে আপনি একটি বাগ পেয়েছেন যা খুঁজে পাওয়া ও ঠিক করা দরকার তবে একটি অসীম লুপ একটি বাগটি বরং সুস্পষ্ট করে তুলেছে।

— ak2

Answer 9

এম্বেড করা বিশ্বে, বিশেষত কোলাহলপূর্ণ পরিবেশে, আপনি অবশ্যই র‌্যামের মতো আচরণ করা উচিত নয়। শর্তসাপেক্ষে (যখন, তবে) যেখানে আপনি '==' বা '! =' ব্যবহার করে তুলনা করেন আপনি সর্বদা ঝুঁকিটি চালান যে আপনার ভেরিয়েবলগুলি সেই গুরুতর মানটি ছেড়ে দেয় যা লুপটি বন্ধ করে দেয় - এতে মারাত্মক পরিণতি হতে পারে - মঙ্গল ল্যান্ডার স্তর ফলাফল। শর্তে '<' বা '>' ব্যবহার করা 'অজানা অজানা' ধরার জন্য একটি অতিরিক্ত স্তরের সুরক্ষা সরবরাহ করে।

মূল উদাহরণে, যদি iঅনভিজ্ঞভাবে 10 এর চেয়ে অনেক বড় মানের কাছে ধরা পড়ে তবে '<' তুলনাটি তত্ক্ষণাত ত্রুটিটি ধরবে এবং লুপটি প্রস্থান করবে, কিন্তু '! =' iগত 0 এবং পিছনে মোড়ানো না হওয়া পর্যন্ত গণনা অবিরত থাকবে 10 এ।

Comments

for (i=4; i<length; i++) csum+=dat[i];বৈধ প্যাকেটগুলির সর্বদা lengthকমপক্ষে চারটির মধ্যে একটির মতো কোডের সাথে অন্য সম্পর্কিত প্রকরণের উপস্থিতি রয়েছে তবে একটিতে দুর্নীতিগ্রস্থ প্যাকেটগুলি পাওয়া যেতে পারে। যদি বিভিন্ন প্যাকেটের ধরণের বিভিন্ন দৈর্ঘ্যের প্রয়োজনীয়তা থাকে তবে প্রতিটি প্যাকেটের প্রকারের জন্য পৃথক প্রসেসিংয়ের অংশ হিসাবে দৈর্ঘ্যটি বৈধতা দিতে চাইতে পারে তবে সাধারণ যুক্তির অংশ হিসাবে প্রথমে চেকসামটি বৈধতা দিতে পারে। যদি একটি নিম্ন-দৈর্ঘ্যের প্যাকেটটি পাওয়া যায়, তবে চেকসাম গণনা "ভাল" বা "খারাপ" প্রতিবেদন করে কিনা তা আসলেই কিছু যায় আসে না, তবে এটি ক্রাশ হওয়া উচিত নয়।

— সুপারক্যাট