গাণিতিক ওভারফ্লো উপেক্ষা করা হয় কেন?


76

আপনার পছন্দসই প্রোগ্রামিং ভাষায় 1 থেকে 2,000,000 পর্যন্ত সমস্ত সংখ্যা যোগ করার চেষ্টা করেছেন? ফলাফলটি ম্যানুয়ালি গণনা করা সহজ: 2,000,001,000,000, যা স্বাক্ষরবিহীন 32 বিট পূর্ণসংখ্যার সর্বোচ্চ মানের চেয়ে 900 গুণ বেশি।

সি # প্রিন্ট আউট -1453759936- একটি নেতিবাচক মান! এবং আমার ধারণা জাভাও তাই করে।

এর অর্থ এমন কিছু সাধারণ প্রোগ্রামিং ল্যাঙ্গুয়েজ রয়েছে যা ডিফল্টরূপে অংকিত ওভারফ্লো উপেক্ষা করে (সি # তে, এটি পরিবর্তনের জন্য লুকানো বিকল্প রয়েছে)। এটি এমন একটি আচরণ যা আমার কাছে খুব ঝুঁকিপূর্ণ বলে মনে হচ্ছে, এবং এরিয়েন 5 এর ক্র্যাশটি এতটা প্রবাহের কারণে হয়নি?

সুতরাং: এই জাতীয় বিপজ্জনক আচরণের পিছনে নকশার সিদ্ধান্তগুলি কী কী?

সম্পাদনা:

এই প্রশ্নের প্রথম উত্তরগুলি চেক করার অতিরিক্ত খরচ প্রকাশ করে। এই অনুমানটি পরীক্ষা করতে আসুন একটি সংক্ষিপ্ত সি # প্রোগ্রাম কার্যকর করুন:

Stopwatch watch = Stopwatch.StartNew();
checked
{
    for (int i = 0; i < 200000; i++)
    {
        int sum = 0;
        for (int j = 1; j < 50000; j++)
        {
            sum += j;
        }
    }
}
watch.Stop();
Console.WriteLine(watch.Elapsed.TotalMilliseconds);

আমার মেশিনে, পরীক্ষিত সংস্করণটি 11015 মিমি লাগে, যখন চেক করা সংস্করণটি 4125 মিমি লাগে। অর্থাত্ চেকিং পদক্ষেপগুলি সংখ্যার যোগ করতে প্রায় দ্বিগুণ সময় নেয় (মূল সময়ের সাথে মোট 3 বার)। তবে 10,000,000,000 পুনরাবৃত্তি সহ, একটি চেকের সময় নেওয়া এখনও 1 ন্যানোসেকেন্ডের চেয়ে কম। এমন পরিস্থিতি থাকতে পারে যেখানে এটি গুরুত্বপূর্ণ, তবে বেশিরভাগ অ্যাপ্লিকেশনগুলির জন্য, এটি গুরুত্বপূর্ণ নয়।

সম্পাদনা 2:

আমি আমাদের সার্ভার অ্যাপ্লিকেশনটি পুনরায় সংকলিত করেছি (একটি উইন্ডোজ পরিষেবাটি বেশ কয়েকটি সেন্সর থেকে প্রাপ্ত তথ্য বিশ্লেষণকারী, বেশ কিছু সংখ্যক ক্রંચিং জড়িত) জড়িত /p:CheckForOverflowUnderflow="false"প্যারামিটার দিয়ে (সাধারণত, আমি ওভারফ্লো চেক অন স্যুইচ করে) এবং এটি একটি ডিভাইসে স্থাপন করি। নাগিওস পর্যবেক্ষণ দেখায় যে গড় সিপিইউ লোড 17% এ দাঁড়িয়েছে।

এর অর্থ হল যে উপরে বর্ণিত উদাহরণটিতে প্রদর্শিত পারফরম্যান্স হিটটি আমাদের আবেদনের জন্য সম্পূর্ণ অপ্রাসঙ্গিক।


19
ঠিক একটি নোট হিসাবে, সি # এর জন্য checked { }আপনি কোডটির যে অংশগুলিতে পাটিগণিত ওভারফ্লো চেকগুলি করা উচিত তা চিহ্নিত করতে বিভাগটি ব্যবহার করতে পারেন । এটি পারফরম্যান্সের কারণে
পাওয়ে Łুকাসিক

14
"আপনার প্রিয় প্রোগ্রামিং ভাষায় 1 থেকে 2,000,000 পর্যন্ত সমস্ত সংখ্যা যোগ করার চেষ্টা করেছেন?" - হ্যাঁ: (1..2_000_000).sum #=> 2000001000000। আমার প্রিয় ভাষায় আরেকটি এক: sum [1 .. 2000000] --=> 2000001000000। না আমার প্রিয়: Array.from({length: 2000001}, (v, k) => k).reduce((acc, el) => acc + el) //=> 2000001000000। (সত্যি বলতে গেলে, শেষটি প্রতারণা করছে))
জার্গ ডব্লু মিতাগ

27
হাস্কেলের @ বার্নহার্ডহিলার Integerনির্বিচারে-নির্ভুলতা রয়েছে, যতক্ষণ না আপনি বরাদ্দযোগ্য র‌্যামটি চালিয়ে না যান ততক্ষণ এটি কোনও সংখ্যা ধরে রাখবে।
বহুভুক্ত

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

9
But with the 10,000,000,000 repetitions, the time taken by a check is still less than 1 nanosecond.এটি লুপটি অনুকূলিত হওয়ার একটি ইঙ্গিত। এছাড়াও সেই বাক্যটি পূর্ববর্তী সংখ্যার সাথে দ্বিধা বোধ করে যা আমার কাছে খুব বৈধ বলে মনে হয়।
usr

উত্তর:


86

এর জন্য 3 টি কারণ রয়েছে:

  1. রান-টাইমে ওভারফ্লোগুলি (প্রতিটি একক পাটিগণিত ক্রিয়াকলাপের জন্য) পরীক্ষা করার ব্যয় অত্যধিক।

  2. সংকলন-সময় একটি ওভারফ্লো চেক বাদ দেওয়া যায় তা প্রমাণ করার জটিলতা অত্যধিক।

  3. কিছু ক্ষেত্রে (যেমন সিআরসি গণনা, বড় সংখ্যক গ্রন্থাগার ইত্যাদি) "ওভারফ্লোতে মোড়ানো" প্রোগ্রামারদের পক্ষে আরও সুবিধাজনক।


10
@ দিমিত্রিগ্রিরিভের মাথায় unsigned intআসা উচিত নয় কারণ ওভারফ্লো চেকিংয়ের সাথে একটি ভাষা ডিফল্টরূপে সমস্ত পূর্ণসংখ্যার প্রকার পরীক্ষা করা উচিত । আপনার লিখতে হবে wrapping unsigned int
ইমিবিস

32
আমি ব্যয় যুক্তি কিনতে না। সিপিইউ প্রতিটি সিঙ্গল ইন্টিজার গণনাতে ওভারফ্লো চেক করে এবং ALU এ ক্যারি পতাকা সেট করে। এটি প্রোগ্রামিং ভাষার সহায়তাটি অনুপস্থিত that's একটি সাধারণ didOverflow()ইনলাইন ফাংশন বা এমনকী একটি বৈশ্বিক পরিবর্তনশীল __carryযা ক্যারি পতাকাটিতে অ্যাক্সেসের অনুমতি দেয় আপনি যদি এটি ব্যবহার না করেন তবে শূন্য সিপিইউ সময় লাগবে।
slebetman

37
@ স্লেবেটম্যান: এটি x86। এআরএম করে না। যেমন ADDক্যারি সেট করে না (আপনার প্রয়োজন ADDS)। Itanium এবং Linux সংক্রান্ত এমনকি নেই আছে একটি বহন পতাকা। এমনকি x86 তেও, AVX এর সাথে পতাকা বহন করে না।
MSalters

30
@ স্লেবেটম্যান এটি বহনকারী পতাকা নির্ধারণ করে, হ্যাঁ (এক্স ৮86-এ, মনে রাখবেন)। তবে তারপরে আপনাকে ক্যারি পতাকাটি পড়তে হবে এবং ফলাফলটি স্থির করতে হবে - এটি ব্যয়বহুল অংশ। যেহেতু পাটিগণিতের ক্রিয়াকলাপগুলি প্রায়শই লুপগুলিতে ব্যবহৃত হয় (এবং এটিতে আঁট লুপ), এটি সহজেই অনেকগুলি নিরাপদ সংকলক অপ্টিমাইজেশানকে আটকাতে পারে যা কেবলমাত্র একটি অতিরিক্ত নির্দেশের প্রয়োজন থাকলেও (এবং এর চেয়ে আরও অনেক বেশি প্রয়োজন) )। এর অর্থ কি এটি ডিফল্ট হওয়া উচিত? হতে পারে, বিশেষত সি # এর মতো ভাষায় যেখানে বলা uncheckedযথেষ্ট সহজ; তবে আপনি প্রায়শই ওভারফ্লো বিষয়টিকে গুরুত্ব দিয়ে দেখছেন।
লুয়ান

12
এআরএম এর addsএকই দাম add(এটি কেবলমাত্র একটি নির্দেশাবলী 1-বিট পতাকা যা ক্যারি পতাকা আপডেট করা হয়েছে কিনা তা নির্বাচন করে)। MIPS এর addওভারফ্লো উপর নির্দেশ যাত্রীর সঙ্গের নিজলটবহর - আপনি আছে জিজ্ঞাসা ব্যবহার করে ওভারফ্লো না ফাঁদে adduপরিবর্তে!
ইমিবিস

65

কে বলেছে এটি খারাপ বাণিজ্য ?!

আমি আমার সমস্ত প্রযোজনা অ্যাপ্লিকেশনগুলিকে ওভারফ্লো চেকিং সক্ষম করে দিয়েছি। এটি একটি সি # সংকলক বিকল্প। আমি আসলে এটি বেঞ্চমার্ক করেছি এবং আমি পার্থক্যটি নির্ধারণ করতে সক্ষম হইনি। (নন খেলনা) এইচটিএমএল তৈরি করতে ডেটাবেস অ্যাক্সেস করার খরচ ওভারফ্লো চেকিংয়ের ব্যয়কে ছাপিয়ে যায়।

আমি সত্য যে আমি জানি যে উত্পাদন কোন অপারেশন ওভারফ্লো যে আমি প্রশংসা করি । প্রায় সমস্ত কোডই উপচে পড়ার উপস্থিতিতে ভ্রান্তভাবে আচরণ করবে। বাগগুলি সৌম্য হবে না। ডেটা দুর্নীতি সম্ভবত, নিরাপত্তা একটি সম্ভাবনা ইস্যু করে।

আমার যদি পারফরম্যান্সের প্রয়োজন হয় যা মাঝে মাঝে হয় তবে আমি unchecked {}দানাদার ভিত্তিতে ওভারফ্লো চেকিংটি অক্ষম করি । যখন আমি কল করতে চাই যে আমি কোনও অপারেশনের উপর নির্ভর করে না যাতে উপচে পড়া প্রবাহিত হয় না তখন আমি checked {}সেই সত্যটি ডকুমেন্ট করার জন্য কোডটিতে অতিরিক্তভাবে যুক্ত করতে পারি । আমি ওভারফ্লোগুলি সম্পর্কে সচেতন তবে চেক করার জন্য আমার অগত্যা ধন্যবাদ হওয়ার দরকার নেই।

আমি বিশ্বাস করি যে সি # টিম যখন ডিফল্টরূপে ওভারফ্লো পরীক্ষা না করা বেছে নিয়েছিল তখন ভুল পছন্দ করেছে তবে দৃ choice ় সামঞ্জস্যতার উদ্বেগের কারণে সেই পছন্দটি এখন সিল করা হয়েছে। দ্রষ্টব্য, এই পছন্দটি 2000 সালের দিকে তৈরি হয়েছিল Hardware হার্ডওয়্যারটি কম সক্ষম ছিল এবং .NET তে এখনও খুব বেশি ট্র্যাকশন দেয়নি। সম্ভবত। নেট এইভাবে জাভা এবং সি / সি ++ প্রোগ্রামারদের কাছে আবেদন করতে চেয়েছিল। .NET অর্থ ধাতুটির কাছাকাছি থাকতে সক্ষম হতে। এ কারণেই এটির অনিরাপদ কোড, স্ট্রাক্ট এবং দুর্দান্ত নেটিভ কল ক্ষমতা রয়েছে যা জাভাতে নেই।

আমাদের হার্ডওয়্যারটি দ্রুততর হয় এবং স্মার্ট আউট সংকলকরা ডিফল্টরূপে আরও আকর্ষণীয় ওভারফ্লো চেকিং পান।

আমি আরও বিশ্বাস করি যে ওভারফ্লো চেকিং অসীম আকারের সংখ্যার চেয়ে প্রায়শই ভাল। অসীম আকারের সংখ্যার একটি পারফরম্যান্স ব্যয় থাকে যা আরও বেশি, অনুকূলকরণ করা শক্ত (আমি বিশ্বাস করি) এবং তারা সীমাহীন সংস্থান ব্যবহারের সম্ভাবনা উন্মুক্ত করে।

ওভারফ্লো মোকাবেলার জাভাস্ক্রিপ্টের পদ্ধতি আরও খারাপ। জাভাস্ক্রিপ্ট নম্বরগুলি ভাসমান পয়েন্ট ডাবল। একটি "ওভারফ্লো" পুরোপুরি নির্ভুল সংখ্যার সেট রেখে নিজেকে প্রকাশ করে। কিছুটা ভুল ফলাফল আসবে (যেমন একের পর এক অফ হয়ে যাওয়া - এটি সসীম লুপগুলিকে অসীমের মধ্যে রূপান্তর করতে পারে)।

কিছু ভাষার ক্ষেত্রে যেমন সি / সি ++ ওভারফ্লো পরীক্ষা করে ডিফল্টরূপে যথাযথভাবে অনুপযুক্ত কারণ এই ভাষাগুলিতে যে ধরণের অ্যাপ্লিকেশন লেখা হচ্ছে তা খালি ধাতব কর্মক্ষমতা প্রয়োজন। তবুও, নিরাপদ মোডে বেছে নেওয়ার অনুমতি দিয়ে সি / সি ++ আরও একটি নিরাপদ ভাষায় পরিণত করার প্রচেষ্টা রয়েছে । 90-99% কোড ঠাণ্ডা লাগে বলে এটি প্রশংসনীয়। একটি উদাহরণ fwrapvসংকলক বিকল্প যা 2 এর পরিপূরক মোড়কে জোর করে। এটি একটি "বাস্তবায়নের মানের" বৈশিষ্ট্যটি ভাষা দ্বারা নয়, সংকলক দ্বারা তৈরি করা হয়েছে।

হাস্কেলের কোনও লজিকাল কল স্ট্যাক এবং কোনও নির্দিষ্ট মূল্যায়ন আদেশ নেই। এটি অপ্রত্যাশিত পয়েন্টগুলিতে ব্যতিক্রম ঘটায়। ইন a + bএটা কিনা অনির্দিষ্ট aবা bপ্রথম মূল্যায়ন করা হয় এবং যারা এক্সপ্রেশন সকল বা না এ বিনষ্ট কিনা। সুতরাং, হাস্কেলের পক্ষে বেশিরভাগ সময় আনবাউন্ড পূর্ণসংখ্যার ব্যবহার করা বোধগম্য। এই পছন্দটি খাঁটি কার্যকরী ভাষার পক্ষে উপযুক্ত কারণ বেশিরভাগ হাস্কেল কোডে ব্যতিক্রমগুলি সত্যই অনুপযুক্ত। এবং শূন্য দ্বারা ভাগ করা প্রকৃতপক্ষে হাস্কেলস ভাষা নকশার একটি সমস্যাযুক্ত বিষয়। আনবাউন্ডেড পূর্ণসংখ্যার পরিবর্তে তারা স্থির-প্রস্থের মোড়ক পূর্ণসংখ্যার পাশাপাশি ব্যবহার করতে পারত তবে ভাষার বৈশিষ্ট্যযুক্ত "নির্ভুলতার উপর ফোকাস" থিমের সাথে এটি খাপ খায় না।

ওভারফ্লো ব্যতিক্রমগুলির বিকল্প হ'ল বিষ মানগুলি যা অপরিবর্তিত অপারেশন দ্বারা তৈরি করা হয় এবং অপারেশনগুলির মাধ্যমে প্রচার করা হয় (ফ্লোট NaNমান হিসাবে)। এটি ওভারফ্লো চেকিংয়ের চেয়ে অনেক ব্যয়বহুল বলে মনে হয় এবং সমস্ত ক্রিয়াকলাপকে ধীর করে দেয়, কেবল ব্যর্থ হতে পারে না (হার্ডওয়ারের ত্বরণ যা সাধারণত ভেসে বেড়ায় এবং সাধারণত ইনটস থাকে না তা বাদ দিয়ে - যদিও ইটানিয়ামে ন্যাটি রয়েছে যা "নট থিং" নয় )। আমি খারাপ ডেটা বরাবর প্রোগ্রামটিকে দুর্বল করে তুলতে পারাও বেশ লক্ষ্য করি না। এটা মত ON ERROR RESUME NEXT। এটি ত্রুটিগুলি আড়াল করে তবে সঠিক ফলাফল পেতে সহায়তা করে না। সুপারক্যাটটি উল্লেখ করে যে এটি কখনও কখনও এটি করার জন্য একটি পারফরম্যান্স অপটিমাইজেশন।


2
দুর্দান্ত উত্তর। তাহলে কেন তারা এইভাবে এটি করার সিদ্ধান্ত নিয়েছে সে সম্পর্কে আপনার তত্ত্বটি কী? সি এবং চূড়ান্তভাবে সমাবেশ এবং বাইনারি অনুলিপি করা প্রত্যেককেই অনুলিপি করছেন?
jpmc26

19
যখন আপনার ব্যবহারকারীর 99% বেস কোনও আচরণের প্রত্যাশা করে, আপনি তাদের এটি দেওয়ার প্রবণতা পান। এবং "সি অনুলিপি করার জন্য" এটি আসলে সি এর অনুলিপি নয়, এটির একটি এক্সটেনশান। সি unsignedকেবল পূর্ণসংখ্যার জন্য ব্যতিক্রম বিনামূল্যে আচরণের গ্যারান্টি দেয় । স্বাক্ষরিত পূর্ণসংখ্যার ওভারফ্লো এর আচরণটি আসলে সি এবং সি ++ এর মধ্যে অপরিবর্তিত আচরণ। হ্যাঁ, অপরিবর্তিত আচরণ । এটি ঠিক তাই ঘটে যে প্রায় সবাই একে 2 এর পরিপূরক ওভারফ্লো হিসাবে প্রয়োগ করে। সি # প্রকৃতপক্ষে এটিকে সি / সি ++ এর মতো ইউবি ছাড়ার পরিবর্তে অফিসিয়াল করে তোলে
কর্ট

10
@ কর্টআ্যাম্মন: ডেনিস রিচি যে ভাষাটি ডিজাইন করেছেন তা স্বাক্ষরিত পূর্ণসংখ্যার জন্য মোড়কযুক্ত আচরণের সংজ্ঞা দিয়েছে, তবে এটি নন-টু-পরিপূরক প্ল্যাটফর্মের জন্য ব্যবহারের জন্য উপযুক্ত নয়। সুনির্দিষ্ট দুটি এর পরিপূরক ওয়্যারপাউন্ড থেকে কিছু বিচক্ষণতা কিছু অপ্টিমাইজেশনকে ব্যাপকভাবে সহায়তা করতে পারে (উদাহরণস্বরূপ একটি সংকলককে x * y / y কে x এর সাথে প্রতিস্থাপনের ফলে একটি গুণ এবং একটি বিভাগ বাঁচাতে পারে), সংকলক লেখকরা অনির্ধারিত আচরণটি করার সুযোগ হিসাবে নয় বলে ব্যাখ্যা করেছেন প্রদত্ত টার্গেট প্ল্যাটফর্ম এবং অ্যাপ্লিকেশন ক্ষেত্রের জন্য কী বোঝায়, বরং উইন্ডোটি থেকে জ্ঞান ফেলে দেওয়ার সুযোগ হিসাবে।
সুপারক্যাট

3
@ কর্টআ্যামমন - এর gcc -O2জন্য উত্পন্ন কোডটি পরীক্ষা করুন x + 1 > x(যেখানে xএটি রয়েছে int)। এছাড়াও gcc.gnu.org/onlinesocs/gcc-6.3.0/gcc/… দেখুন । সি সাইন ইন ওভারফ্লো উপর 2s-সম্পূরক আচরণ ঐচ্ছিক , বাস্তব কম্পাইলার এমনকি এবং gccস্বাভাবিক অপ্টিমাইজেশান মাত্রা এটি উপেক্ষা ডিফল্ট।
জনাথন কাস্ট

2
@ সুপের্যাট হ্যাঁ, বেশিরভাগ সি সংকলক লেখকরা প্রোগ্রামারগুলিকে যুক্তিসঙ্গত শব্দার্থ সরবরাহ করার চেষ্টা করার চেয়ে কিছু অবাস্তব বেঞ্চমার্ক 0.5% দ্রুত চালিত হয় তা নিশ্চিত করতে আগ্রহী (হ্যাঁ আমি বুঝতে পারি কেন এটি সমাধান করা সহজ সমস্যা নয় এবং কিছু যুক্তিসঙ্গত আশাবাদ রয়েছে যার কারণ হতে পারে) একত্রিত হওয়ার পরে অপ্রত্যাশিত ফলাফল, ইয়াদ, ইয়াদ কিন্তু তবুও এটি কেবল কোনও মনোযোগ নেই এবং আপনি কথোপকথনগুলি অনুসরণ করেন তবে আপনি এটি লক্ষ্য করবেন)। ভাগ্যক্রমে এমন কিছু লোক আছেন যারা আরও ভাল করার চেষ্টা করেন
ভু

30

কারণ এটি একটি খারাপ ট্রেড বন্ধ করতে এর সব হিসাব আরো অনেক অর্ডার স্বয়ংক্রিয়ভাবে বিরল ক্ষেত্রে যে একটি ওভারফ্লো ধরা মধ্যে ব্যয়বহুল করে ঘটে থাকে। প্রোগ্রামারকে বিরল ক্ষেত্রে কে এটির সমস্যা স্বীকৃতি দিয়ে বোঝাতে আরও ভাল হয় এবং সমস্ত প্রোগ্রামার তাদের ব্যবহার না করে এমন কার্যকারিতার জন্য মূল্য প্রদান করার চেয়ে বিশেষ প্রতিরোধ যুক্ত করে ।


28
এটি একরকম বলার মতো যে বাফার ওভারফ্লোর জন্য চেকগুলি বাদ দেওয়া উচিত কারণ এগুলি খুব কমই ঘটে ...
বার্নহার্ড হিলার

73
@ বার্নহার্ডহিলার: এবং সি ও সি ++ ঠিক তাই করে।
মাইকেল বর্গওয়ার্ট

12
@ ডেভিডব্রাউন: যেমন পাটিগণিতের ওভারফ্লো হয়েছে। প্রাক্তন যদিও ভিএম এর সাথে আপস করেন না।
উত্সাহক

35
@ উত্সাহক একটি দুর্দান্ত পয়েন্ট করেছেন makes সিএলআরটি সাবধানে ডিজাইন করা হয়েছিল যাতে যাচাইযোগ্য প্রোগ্রামগুলি খারাপ জিনিস ঘটে এমনকি রানটাইমের আক্রমণকারীদের লঙ্ঘন করতে না পারে। যখন খারাপ জিনিস ঘটে তখন নিরাপদ প্রোগ্রাম অবশ্যই তাদের নিজস্ব আক্রমণকারীদের লঙ্ঘন করতে পারে।
এরিক লিপার্ট

7
@ এসভিক অ্যারিমেটিক অপারেশন সম্ভবত অ্যারে ইনডেক্সিং অপারেশনগুলির চেয়ে অনেক বেশি সাধারণ। এবং বেশিরভাগ পূর্ণসংখ্যার আকারগুলি এত বড় যে গাণিতিক সম্পাদন করা খুব বিরল over সুতরাং ব্যয়-বেনিফিট অনুপাতগুলি খুব আলাদা।
বর্মার

20

এই ধরনের বিপজ্জনক আচরণের পিছনে নকশার সিদ্ধান্তগুলি কী কী?

"ব্যবহারকারীদের এমন কোনও বৈশিষ্ট্যের জন্য পারফরম্যান্স জরিমানা দিতে বাধ্য করবেন না যাতে তাদের প্রয়োজন হয় না।"

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

আরও নতুন বৈশিষ্ট্য যেমন অ্যারে বাউন্ডস চেকিংয়ের জন্য এই দৃষ্টিভঙ্গির সাথে আরও নতুন ভাষা ভেঙে যায়। ওভারফ্লো চেক করার জন্য তারা কেন এটি করেন নি আমি নিশ্চিত নই; এটি কেবল একটি পর্যবেক্ষণ হতে পারে।


18
এটি অবশ্যই সি # এর ডিজাইনে কোনও তদারকি নয়। সি # এর ডিজাইনাররা ইচ্ছাকৃতভাবে দুটি মোড তৈরি করেছিলেন: checkedএবং uncheckedস্থানীয়ভাবে তাদের মধ্যে স্যুইচ করার জন্য সিনট্যাক্স যুক্ত করেছিলেন এবং এটি বিশ্বব্যাপী পরিবর্তনের জন্য কমান্ড লাইন সুইচগুলি (এবং ভিএস-তে প্রকল্পের সেটিংস )ও যুক্ত করেছিলেন। আপনি সম্ভবত uncheckedডিফল্ট (আমি করি) তৈরির সাথে একমত নন , তবে এটি সমস্ত স্পষ্টভাবে খুব ইচ্ছাকৃত।
এসভিক

8
@ স্লেবেটম্যান - কেবলমাত্র রেকর্ডের জন্য: এখানকার ব্যয় ওভারফ্লো (যা তুচ্ছ) পরীক্ষা করার ব্যয় নয়, ওভারফ্লো হয়েছে কিনা তার উপর নির্ভর করে বিভিন্ন কোড চালনার ব্যয় (যা খুব ব্যয়বহুল)। সিপিইউগুলি শর্তসাপেক্ষ শাখার বিবৃতি পছন্দ করে না।
জোনাথন কাস্ট

5
@ জাস্ট জাস্ট আধুনিক প্রসেসরগুলির উপর ভবিষ্যদ্বাণীগুলি কি শর্তসাপেক্ষ শাখা বিবৃতি জরিমানা প্রায় অপসারণ করে না? সর্বোপরি সাধারণ ক্ষেত্রে কোনও ওভারফ্লো হওয়া উচিত নয়, সুতরাং এটি খুব অনুমানযোগ্য শাখা আচরণ।
কোডমনেকি

4
@ কোডডমঙ্কির সাথে সম্মত হন। একটি সংকলক সাধারণত অতিরিক্ত লোড / ঠান্ডা নয় এমন একটি পৃষ্ঠায় ওভারফ্লোর ক্ষেত্রে শর্তযুক্ত ঝাঁপ দাও। এর জন্য ডিফল্ট ভবিষ্যদ্বাণীটি "নেওয়া হয়নি", এবং সম্ভবত এটি পরিবর্তন হবে না। পাইপলাইনে মোট ওভারহেড একটি নির্দেশ। তবে এটি পাটিগণিতের নির্দেশ অনুসারে একটি নির্দেশ ওভারহেড।
এমসাল্টারস 9:47

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

20

উত্তরাধিকার

আমি বলব যে সমস্যাটি সম্ভবত উত্তরাধিকারের মূল। সি তে:

  • স্বাক্ষরিত ওভারফ্লো হ'ল অপরিজ্ঞাত আচরণ (কম্পাইলারগুলি এটি মোড়ানো করতে পতাকা সমর্থন করে),
  • স্বাক্ষরযুক্ত ওভারফ্লো সংজ্ঞায়িত আচরণ (এটি মোড়ানো)।

প্রোগ্রামার জানেন যে এটি কী করছে তা নীতির অনুসরণ করে সেরা সম্ভাব্য পারফরম্যান্স পাওয়ার জন্য এটি করা হয়েছিল ।

স্ট্যাটু-কোয়োর দিকে নিয়ে যায়

সি (এবং এক্সটেনশান সি ++ দ্বারা) ঘুরে ওভারফ্লো সনাক্তকরণের প্রয়োজন হয় না এর অর্থ ওভারফ্লো চেক করা খুব কম।

হার্ডওয়্যার বেশিরভাগ সি / সি ++ পূরণ করে (গুরুতরভাবে, x86 এর একটি strcmpনির্দেশনা রয়েছে ( এসএসই 4.2 হিসাবে ওরফে পিসিএমপিআইএসটিআই !)), এবং যেহেতু সি পাত্তা দেয় না, সাধারণ সিপিইউগুলি ওভারফ্লো সনাক্ত করার কার্যকর উপায় সরবরাহ করে না। X86 এ, প্রতিটি সম্ভাব্য উপচে পড়া অপারেশনের পরে আপনাকে প্রতি-কোর ফ্ল্যাগটি পরীক্ষা করতে হবে; আপনি যখন যা চান তা হ'ল ফলাফলের একটি "কলঙ্কিত" পতাকা (অনেকটা এনএএন প্রচার করে। এবং ভেক্টর অপারেশনগুলি আরও বেশি সমস্যাযুক্ত হতে পারে। কিছু নতুন খেলোয়াড় দক্ষ ওভারফ্লো পরিচালনা সহ বাজারে উপস্থিত হতে পারে; তবে আপাতত x86 এবং এআরএম যত্ন নিচ্ছে না।

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

ক্যাসকেডিং প্রভাব সহ

সুতরাং, দক্ষ অপ্টিমাইজেশান কৌশল এবং দক্ষ সিপিইউ সহায়তার অভাবে, ওভারফ্লো পরীক্ষা করা ব্যয়বহুল। মোড়কের চেয়ে অনেক বেশি ব্যয়বহুল।

কিছু বিরক্তিকর আচরণে যুক্ত করুন, যেমন x + y - 1কখন x - 1 + yনা ওভারফ্লো হতে পারে যা ব্যবহারকারীদের বৈধভাবে বিরক্ত করতে পারে এবং ওভারফ্লো চেকিং সাধারণত মোড়ানোর পক্ষে বাতিল করা হয় (যা এই উদাহরণটি এবং অন্যান্য অনেককে নিখুঁতভাবে পরিচালনা করে)।

তবুও, সমস্ত আশা হারিয়ে যায় না

"স্যানিটাইজারস" প্রয়োগ করার জন্য ঝনঝন এবং জিসিসি সংকলকগুলিতে একটি প্রচেষ্টা হয়েছে: অনির্ধারিত আচরণের ক্ষেত্রে সনাক্ত করার জন্য বাইনারিগুলি উপকরণের উপায় ways ব্যবহার করার সময় -fsanitize=undefined, স্বাক্ষরিত ওভারফ্লো সনাক্ত হয় এবং প্রোগ্রামটি বন্ধ করে দেয়; পরীক্ষার সময় খুব দরকারী।

মরচে প্রোগ্রামিং ভাষা ওভারফ্লো-পরীক্ষণ সক্ষম কিনা ডিফল্টরূপে ডিবাগ মোডে (এটা কর্মক্ষমতা কারণে রিলিজ মোডে গাণিতিক মোড়কে ব্যবহার করে)।

সুতরাং, ওভারফ্লো পরীক্ষা-নিরীক্ষা এবং বোগাস ফলাফলের ঝুঁকিগুলি সনাক্ত করা যায় না এমন বিষয়ে উদ্বেগ বাড়ছে এবং আশা করি এটি গবেষণা সম্প্রদায়, সংকলক সম্প্রদায় এবং হার্ডওয়্যার সম্প্রদায়ের প্রতি আগ্রহের জন্ম দেবে।


6
@ দিমিত্রিগ্রিরিভ যা ওভারফ্লোগুলি পরীক্ষা করার কার্যকর পদ্ধতির বিপরীত, উদাহরণস্বরূপ হাসওলে এটি চক্র প্রতি 4 টি সাধারণ সংযোজন থেকে কেবল 1 টি পরীক্ষিত সংযোজনকে আউটপুট হ্রাস করে এবং এর শাখার ভুল-প্রভাবের প্রভাব বিবেচনা করার আগে joএবং দূষণের আরও বিশ্বব্যাপী প্রভাবগুলি তারা শাখার পূর্বাভাসকারী রাষ্ট্র এবং কোডের আকারের বর্ধিত করে। যদি পতাকাটি আঠালো থাকে তবে এটি কিছু বাস্তব সম্ভাবনা দেবে .. এবং তারপরে আপনি এখনও এটি ভেক্টরাইজড কোডে সঠিকভাবে করতে পারবেন না।

3
যেহেতু আপনি জন রেগারের লেখা একটি ব্লগ পোস্টের সাথে লিঙ্ক করছেন , তাই আমি যুক্ত করেছি যে আপনি লিঙ্ক করেছেন তার কয়েক মাস আগে লেখা তাঁর আর একটি নিবন্ধের সাথে লিঙ্ক করাও উপযুক্ত হবে । এই নিবন্ধগুলি বিভিন্ন দর্শন সম্পর্কে আলোচনা করে: পূর্ববর্তী নিবন্ধে, পূর্ণসংখ্যাগুলি নির্দিষ্ট আকারের হয়; পূর্ণসংখ্যার গাণিতিক পরীক্ষা করা হয় (উদাহরণস্বরূপ কোডটি তার প্রয়োগ চালিয়ে যেতে পারে না); ব্যতিক্রম বা ফাঁদ আছে। নতুন নিবন্ধটি পুরোপুরি স্থির আকারের পূর্ণসংখ্যার খনন সম্পর্কে কথা বলে, যা ওভারফ্লোগুলি দূর করে।
রওয়ং

2
@ রুং অসীম আকারের পূর্ণসংখ্যাগুলিরও তাদের সমস্যা রয়েছে। যদি আপনার ওভারফ্লো কোনও বাগের ফলাফল হয় (যা এটি প্রায়শই হয়) তবে এটি দ্রুত ক্রাশটিকে দীর্ঘায়িত যন্ত্রণায় পরিণত করতে পারে যা সমস্ত সার্ভার সংস্থান গ্রহণ করে যতক্ষণ না সমস্ত কিছু ভয়াবহভাবে ব্যর্থ হয়। আমি বেশিরভাগই "ব্যর্থ শীঘ্র" পদ্ধতির ভক্ত - পুরো পরিবেশকে বিষক্রিয়া করার সম্ভাবনা কম। আমি এর 1..100পরিবর্তে পাস্কাল-ইশ প্রকারগুলি পছন্দ করতাম - 2 ^ 31 এ "বাধ্য" না হয়ে প্রত্যাশিত পরিসীমা সম্পর্কে স্পষ্ট থাকি । কিছু ভাষায় অবশ্যই এই অফার দেওয়া হয় এবং এগুলি ডিফল্টরূপে ওভারফ্লো চেকিংয়ের ঝোঁক থাকে (কখনও কখনও সংকলন-সময়, এমনকি)।
লুয়ান

1
@ লুয়ান: মজার বিষয়টি হ'ল প্রায়শই মধ্যবর্তী গণনাগুলি অস্থায়ীভাবে উপচে পড়তে পারে তবে ফলাফলটি আসে না। উদাহরণস্বরূপ, আপনার ১.১০০ পরিসরে, ফলাফলটি মাপসই হওয়া সত্ত্বেও is১ বছর বয়সে x * 2 - 2উপচে পড়তে পারে , আপনাকে আপনার গণনাটি xপুনরায় সাজানোর জন্য বাধ্য করে (কখনও কখনও অপ্রাকৃত উপায়ে)। আমার অভিজ্ঞতাতে, আমি খুঁজে পেয়েছি যে আমি সাধারণত একটি বৃহত ধরণের গণনা চালানো পছন্দ করি এবং তারপরে ফলাফলটি খাপ খায় কিনা তা পরীক্ষা করে দেখুন।
ম্যাথিউ এম

1
@MatthieuM। হ্যাঁ, আপনি সেখানে "পর্যাপ্ত পরিমাণে স্মার্ট সংকলক" অঞ্চলে প্রবেশ করুন। আদর্শভাবে, 103 এর মান 1.100 প্রকারের জন্য বৈধ হওয়া উচিত যতক্ষণ না এটি কখনই প্রকৃত 1..100 প্রত্যাশিত প্রসঙ্গে ব্যবহৃত হয় না (উদাহরণস্বরূপ , অ্যাসাইনমেন্টটি কার্যকর বৈধ 1-এ ফলাফল প্রাপ্ত x = x * 2 - 2সকলের জন্য কাজ করা উচিত) x। .100 নম্বর)। এটি হ'ল সংখ্যার ধরণের ক্রিয়াকলাপ যতক্ষণ অ্যাসাইনমেন্টের সাথে খাপ খায় ততক্ষণ টাইপ থেকে তার চেয়ে বেশি নির্ভুলতা থাকতে পারে। এটি ক্ষেত্রে ক্ষেত্রে বেশ কার্যকর হবে যেমন (a + b) / 2উপেক্ষা করা (স্বাক্ষরবিহীন) ওভারফ্লোগুলি সঠিক বিকল্প হতে পারে।
লুয়ান

10

যে ভাষাগুলি ওভারফ্লোগুলি সনাক্ত করার চেষ্টা করে তারা seতিহাসিকভাবে সম্পর্কিত শব্দার্থবিজ্ঞানকে এমনভাবে সংজ্ঞায়িত করেছে যা অন্যথায় দরকারী অপটিমাইজেশন হতে পারে এমনটি কঠোরভাবে সীমাবদ্ধ করে। অন্যান্য জিনিসের মধ্যে, যদিও কোডে নির্দিষ্ট কিছু থেকে আলাদা ধারাবাহিকতায় গণনা সম্পাদন করা প্রায়শই কার্যকর হবে, বেশিরভাগ ভাষাগুলি যেগুলি ফাঁকে ফাঁকে ফাঁকে ফেলা হয় সেই প্রদত্ত কোডটির গ্যারান্টি দেয়:

for (int i=0; i<100; i++)
{
  Operation1();
  x+=i;
  Operation2();
}

যদি x এর প্রারম্ভিক মানটি লুপের মধ্য দিয়ে 47 তম পাসে ওভারফ্লো হতে পারে, অপারেশন 1 47 বার কার্যকর করবে এবং অপারেশন 2 46 চালায়। অপারেশন 1 বা অপারেশন 2 দ্বারা নিক্ষিপ্ত ব্যতিক্রমের পরে x এর মান ব্যবহার করা হবে, কোডটি এর সাথে প্রতিস্থাপন করা যেতে পারে:

x+=4950;
for (int i=0; i<100; i++)
{
  Operation1();
  Operation2();
}

দুর্ভাগ্যক্রমে, লুপের মধ্যে একটি ওভারফ্লো ঘটেছে এমন ক্ষেত্রে সঠিক শব্দার্থবিজ্ঞানের গ্যারান্টি দেওয়ার সময় এই ধরনের অপ্টিমাইজেশানগুলি সম্পাদন করা কঠিন - মূলত এর মতো কিছু প্রয়োজন:

if (x < INT_MAX-4950)
{
  x+=4950;
  for (int i=0; i<100; i++)
  {
    Operation1();
    Operation2();
  }
}
else
{
  for (int i=0; i<100; i++)
  {
    Operation1();
    x+=i;
    Operation2();
  }
}

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

ওভারফ্লো সনাক্তকরণ সস্তা করার জন্য কী প্রয়োজন হবে তা হ'ল আলগা ওভারফ্লো-সনাক্তকরণ শব্দার্থবিজ্ঞানের একটি সংজ্ঞায়িত সেট যা ফলাফলের (*) প্রভাব ফেলতে পারে এমন কোনও ওভারফ্লো ছাড়াই কোনও গণনা সম্পাদন করা হয়েছিল কিনা তা রিপোর্ট করা কোডের পক্ষে সহজ করে দেয়, তবে বোঝা ছাড়াই এর বাইরে বিশদ সহ সংকলক। যদি কোনও ভাষার বৈশিষ্ট্য উপরেরটি অর্জনের জন্য প্রয়োজনীয় ন্যূনতমের তুলনায় ওভারফ্লো সনাক্তকরণের ব্যয় হ্রাস করার দিকে মনোনিবেশ করে, তবে এটি বিদ্যমান ভাষাগুলির তুলনায় এটি অনেক কম ব্যয়বহুল হতে পারে। দক্ষ ওভারফ্লো সনাক্তকরণের সুবিধার্থে কোনও প্রচেষ্টা সম্পর্কে আমি অসচেতন।

(*) যদি কোনও ভাষা প্রতিশ্রুতি দেয় যে সমস্ত ওভারফ্লোগুলি প্রতিবেদন করা হবে, তবে তার মতো অভিব্যক্তিটি x*y/yসরল করা যাবে না xযতক্ষণ x*yনা ওভারফ্লো না হওয়ার নিশ্চয়তা দেওয়া যায় না। তেমনি, কোনও গণনার ফলাফল উপেক্ষা করা হলেও, এমন একটি ভাষা যা সমস্ত ওভারফ্লোগুলি প্রতিবেদন করার প্রতিশ্রুতি দেয় তা এটিকে যেভাবেই করা দরকার তাই এটি ওভারফ্লো চেক সম্পাদন করতে পারে। যেহেতু এই জাতীয় ক্ষেত্রে ওভারফ্লো গণিত-ভুল আচরণের ফলস্বরূপ হতে পারে না, তাই কোনও প্রোগ্রামের গ্যারান্টি দেওয়ার জন্য এই ধরনের চেক সঞ্চালনের প্রয়োজন হবে না যে কোনও অতিরিক্ত প্রবহমান সম্ভাব্য-অসম্পূর্ণ ফলাফলের কারণ হয়ে উঠেনি।

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

#include <stdint.h>
uint32_t test(uint16_t x, uint16_t y) { return x*y & 65535u; }
uint32_t test2(uint16_t q, int *p)
{
  uint32_t total=0;
  q|=32768;
  for (int i = 32768; i<=q; i++)
  {
    total+=test(i,65535);
    *p+=1;
  }
  return total;
}

জিসিসি পরীক্ষার জন্য কোড তৈরি করবে যা নিঃশর্তভাবে একবার (* পি) ইনক্রিমেন্ট করে এবং কিউতে যে মান নির্বিশেষে 32768 প্রদান করে। এর যুক্তি দ্বারা, (32769 * 65535) এবং 65535u এর গণনা একটি উপচে পড়বে এবং এইভাবে সংকলকটির এমন কোনও ক্ষেত্রে বিবেচনা করার প্রয়োজন নেই যেখানে (q | 32768) 32768 এর চেয়ে বেশি মূল্য অর্জন করতে পারে though যদিও কোনও নেই (32769 * 65535) এবং 65535u এর গণনার ফলাফলের উপরের বিটগুলির যত্ন নেওয়া উচিত কারণ, জিসিসি লুপটিকে উপেক্ষা করার জন্য ন্যায়সঙ্গত হিসাবে স্বাক্ষরিত ওভারফ্লো ব্যবহার করবে।


2
"এটি আধুনিক সংকলকগুলির জন্য ফ্যাশনেবল ..." - একইভাবে, কিছু নামকরা কার্নেলের বিকাশকারীরা তাদের ব্যবহৃত অপটিমাইজেশন ফ্ল্যাগ সম্পর্কিত ডকুমেন্টেশন না পড়তে এবং তারপরে পুরো ইন্টারনেটে ক্রুদ্ধ আচরণ করার জন্য এটি সংক্ষিপ্তভাবে ফ্যাশনেবল ছিল was কারণ তারা তাদের পছন্দসই আচরণটি পেতে আরও বেশি সংকলক পতাকা যুক্ত করতে বাধ্য হয়েছিল ;-)। এই ক্ষেত্রে, -fwrapv, সংজ্ঞায়িত আচরণের ফলাফল না আচরণ প্রশ্নকারী চায় যদ্যপি। মঞ্জুর, জিসিসি অপ্টিমাইজেশান স্ট্যান্ডার্ড এবং সংকলক আচরণের উপর পুরোপুরি পরীক্ষায় কোনও ধরণের সি বিকাশকে পরিণত করে।
স্টিভ জেসপ

1
@ স্টিভ জেসাপ: সংকলক লেখকরা নিম্ন-স্তরের উপভাষাকে স্বীকৃতি দেয় যেখানে সিটি অনেক বেশি স্বাস্থ্যকর ভাষা হতে পারে যেখানে "অপরিজ্ঞাত আচরণ" বলতে "অন্তর্নিহিত প্ল্যাটফর্মের উপর যা কিছু বোঝাতে চাইবে তাই করে" এবং এরপরে প্রোগ্রামারদের অপ্রয়োজনীয় গ্যারান্টি ছাড়ার উপায় যুক্ত করে, স্ট্যান্ডার্ডে "অ-বহনযোগ্য বা ভ্রষ্ট" বাক্যাংশটির সহজ অর্থ "ভ্রান্ত" বলে অনুমান করার পরিবর্তে। অনেক ক্ষেত্রে, দুর্বল আচরণগত গ্যারান্টি সহ কোনও ভাষায় যে অনুকূল কোড পাওয়া যায় সেগুলি শক্তিশালী গ্যারান্টি বা কোনও গ্যারান্টি সহ প্রাপ্তির চেয়ে আরও ভাল। উদাহরণস্বরূপ ...
সুপারক্যাট

1
... যদি কোনও প্রোগ্রামার এমন x+y > zকোনও ফ্যাশনে মূল্যায়ন করার প্রয়োজন হয় যা ফলন 0 বা ফলন 1 ব্যতীত আর কখনও কিছু না করে তবে ওভারফ্লোর ক্ষেত্রে ফলাফলটি সমানভাবে গ্রহণযোগ্য হবে, এমন একটি সংকলক যা গ্যারান্টি দেয় যে প্রায়শই আরও ভাল কোড তৈরি করতে পারে x+y > zযে কোনও সংকলকটির চেয়ে এক্সপ্রেশন অভিব্যক্তিটির একটি রক্ষণাত্মকভাবে লিখিত সংস্করণ তৈরি করতে সক্ষম হবে। বাস্তবের ভাষায় বলতে গেলে, বিভাগের / বাকী অংশ ছাড়া অন্য পূর্ণসংখ্যার গণনাগুলি কোনও পার্শ্ব-প্রতিক্রিয়া ছাড়াই কার্যকর গ্যারান্টি দ্বারা দরকারী ওভারফ্লো-সম্পর্কিত অপ্টিমাইজেশনের কোন ভগ্নাংশকে বাদ দেওয়া হবে?
সুপারক্যাট

আমি স্বীকার করি যে আমি বিশদটি পুরোপুরি আছি না, তবে আপনার তাত্পর্য সাধারণভাবে "সংকলক লেখকদের" সাথে রয়েছে এবং বিশেষত "জিসিসি-তে থাকা কেউ না যারা আমার -fwhatever-makes-senseপ্যাচ গ্রহণ করবেন না ", দৃ strongly়তার সাথে পরামর্শ দেয় যে আরও কিছু আছে এটি তাদের পক্ষ থেকে ঝকঝকে চেয়ে। আমি যে সাধারণ যুক্তি শুনেছি তা হ'ল কোড ইনলাইনিং (এবং এমনকি ম্যাক্রো এক্সপেনশন) কোনও কোড কনস্ট্রাক্টের সুনির্দিষ্ট ব্যবহার সম্পর্কে যতটা সম্ভব কেটে নেওয়া থেকে উপকৃত হয়, যেহেতু দুটি জিনিসই সাধারণত সন্নিবেশিত কোডের ফলাফল দেয় যা এর প্রয়োজন হয় না এমন ক্ষেত্রে ডিল করে thing যাও, যে আশেপাশের কোড "প্রমাণিত" অসম্ভব।
স্টিভ জেসপ

সুতরাং সরলীকৃত উদাহরণের জন্য, যদি আমি লিখি foo(i + INT_MAX + 1), সংকলক-লেখকরা ইনলাইনড কোডটিতে অপ্টিমাইজেশন প্রয়োগ করতে আগ্রহী foo()যা এটির যুক্তিটি অ-নেতিবাচক হওয়ার জন্য নির্ভুলতার জন্য নির্ভর করে (সম্ভবত পিতামহী ডিভোড ট্রিকস)। আপনার অতিরিক্ত বিধিনিষেধের আওতায় তারা কেবলমাত্র অনুকূলিত্ব প্রয়োগ করতে পারে যার নেতিবাচক ইনপুটগুলির জন্য আচরণ প্ল্যাটফর্মটির জন্য অর্থবোধ করে। অবশ্যই, ব্যক্তিগতভাবে আমি এর জন্য -fস্যুইচ করে এমন একটি বিকল্প হতে পেরে খুশি হব -fwrapvএবং সম্ভবত কিছু অপ্টিমাইজেশন অক্ষম করতে হবে যার জন্য কোনও পতাকা নেই। তবে আমি নিজের মতো করে সমস্ত কাজ করতে বিরক্ত হতে পারি এমনটা নয়।
স্টিভ জেসপ

9

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

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


নোট করুন যে ওভারফ্লো সনাক্তকরণের মধ্যে পার্থক্য রয়েছে (এবং তারপরে একটি সংকেত, প্যানিক, ব্যতিক্রম, ...) এবং বড় সংখ্যায় স্যুইচ করতে হবে। পূর্ববর্তীটির তুলনায় আধুনিকের তুলনায় অনেক বেশি সস্তা ব্যয় করা উচিত।
ম্যাথিউ এম

@MatthieuM। অবশ্যই - এবং আমি বুঝতে পারি যে আমি আমার উত্তরে সে সম্পর্কে পরিষ্কার নই।
নেমানজা ত্রিফুনোভিচ

7

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

আপনি যদি এমন একটি নতুন ভাষা চালু করেন যা বেশিরভাগ ক্ষেত্রে সি # এর সমান হয় তবে 3 গুণ ধীর গতির হয়, বাজার ভাগ পাওয়া সহজ হবে না, যদিও শেষ পর্যন্ত আপনার বেশিরভাগ শেষ ব্যবহারকারীরা ওভারফ্লো চেকগুলি থেকে আরও বেশি উপকার পাবেন উচ্চতর কর্মক্ষমতা থেকে।


10
এটি সি # এর ক্ষেত্রে বিশেষত ছিল যা জাভা এবং সি ++ এর তুলনায় প্রথমদিকে ছিল বিকাশকারী উত্পাদনশীলতা মেট্রিকগুলিতে নয়, যা পরিমাপ করা শক্ত, বা-নগদ-সুরক্ষিত নয়-লেনদেন-না-সুরক্ষা-লঙ্ঘন মেট্রিকগুলিতে, যা পরিমাপ করা শক্ত, তবে তুচ্ছ পারফরম্যান্সের মানদণ্ডে।
এরিক লিপার্ট

1
এবং সম্ভবত, সিপিইউর কর্মক্ষমতা কিছু সাধারণ সংখ্যার ক্রাঞ্চিংয়ের সাথে চেক করা হয়েছে। সুতরাং ওভারফ্লো সনাক্তকরণের জন্য অপ্টিমাইজেশনগুলি সেই পরীক্ষাগুলিতে "খারাপ" ফলাফল দিতে পারে। ধরা 22.
বার্নহার্ড হিলার

5

পারফরম্যান্সের ভিত্তিতে ওভারফ্লো চেকিংয়ের অভাবকে ন্যায্যতা দেয় এমন অনেক উত্তরের বাইরে, দুটি পৃথক গণিত বিবেচনা করতে হবে:

  1. সূচকের গণনা (অ্যারে ইনডেক্সিং এবং / অথবা পয়েন্টার পাটিগণিত)

  2. অন্যান্য গাণিতিক

ভাষা যদি পয়েন্টার আকারের সমান একটি পূর্ণসংখ্যার আকার ব্যবহার করে তবে একটি ভালভাবে নির্মিত প্রোগ্রাম সূচীকরণের গণনাগুলি উপরি প্রবাহিত করবে না কারণ সূচীকরণের গণনাগুলি ওভারফ্লো হওয়ার আগে অবশ্যই মেমরির বাইরে চলে যেতে হবে।

সুতরাং, বরাদ্দকৃত ডেটা স্ট্রাকচারের সাথে জড়িত পয়েন্টার গাণিতিক এবং সূচক এক্সপ্রেশনগুলির সাথে কাজ করার সময় মেমরি বরাদ্দগুলি পরীক্ষা করা যথেষ্ট। উদাহরণস্বরূপ, যদি আপনার কাছে 32-বিট ঠিকানার স্থান থাকে এবং 32-বিট পূর্ণসংখ্যা ব্যবহার করা হয় এবং সর্বাধিক 2GB হিপ বরাদ্দ দেওয়া হয় (ঠিকানার প্রায় অর্ধেক স্থান), সূচক / পয়েন্টার গণনা (মূলত) উপচে পড়বে না।

আরও, আপনি বিস্মিত হতে পারেন যে সংযোজন / বিয়োগ / গুণটির কতটা অ্যারে ইনডেক্সিং বা পয়েন্টার গণনা জড়িত, এইভাবে প্রথম বিভাগে পড়ে। অবজেক্ট পয়েন্টার, ফিল্ড অ্যাক্সেস এবং অ্যারে ম্যানিপুলেশনগুলি ক্রিয়াকলাপকে সূচক করে তোলা হয় এবং অনেকগুলি প্রোগ্রাম এর চেয়ে পাটিগণিতের আর কোনও গণনা করে না! মূলত, এটি প্রাথমিক কারণ হিসাবে প্রোগ্রামগুলি কাজ করে পাশাপাশি পূর্ণসংখ্যার ওভারফ্লো চেকিং ছাড়াই করে।

সমস্ত অ-সূচক এবং অ-পয়েন্টার কম্পিউটেশনগুলিকে শ্রেণীবদ্ধ করা উচিত যেগুলি ওভারফ্লো চায় (যেমন হ্যাশিং কম্পিউটেশন) চায় এবং তাদের (যেমন আপনার সারসংক্ষেপ উদাহরণ))

পরবর্তী ক্ষেত্রে, প্রোগ্রামাররা প্রায়শই বিকল্প ডেটা ধরণ যেমন doubleকিছু বা কিছু ব্যবহার করবে BigInt। অনেক গণনার জন্য decimalডেটা ধরণের প্রয়োজন double, যেমন আর্থিক গণনা। যদি তারা না থাকে এবং পূর্ণসংখ্যার ধরণের সাথে আটকে থাকে, তবে তাদের পূর্ণসংখ্যার ওভারফ্লো পরীক্ষা করার জন্য তাদের যত্ন নেওয়া দরকার - বা অন্যথায় হ্যাঁ, আপনি নির্দেশ করছেন বলে প্রোগ্রামটি একটি সনাক্ত করা ত্রুটি শর্তে পৌঁছতে পারে।

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


3

ডিস্টিং বিল্ডের জন্য চেক যোগ করে এবং অপ্টিমাইজড রিলিজ সংস্করণে তাদের অপসারণ করে ওভারফ্লোগুলি পরীক্ষা করার মধ্যে এবং না জঞ্জাল ভাষা মজাদার একটি আকর্ষণীয় সমঝোতা সরবরাহ করে। এটি আপনাকে পরীক্ষার সময় বাগগুলি খুঁজে পেতে দেয়, তবুও চূড়ান্ত সংস্করণে সম্পূর্ণ পারফরম্যান্স পেয়ে থাকে।

যেহেতু ওভারফ্লো র্যাপআরাউন্ড কখনও কখনও আচরণের প্রয়োজন হয়, অপারেটরগুলির এমন সংস্করণও রয়েছে যা কখনই ওভারফ্লো পরীক্ষা করে না।

পরিবর্তনের জন্য আপনি আরএফসিতে পছন্দ করার পিছনে যুক্তি সম্পর্কে আরও পড়তে পারেন । এই ব্লগ পোস্টে প্রচুর আকর্ষণীয় তথ্য রয়েছে , এতে বাগের একটি তালিকা রয়েছে যা এই বৈশিষ্ট্যটি ধরতে সহায়তা করেছে।


2
মরিচা এমন পদ্ধতিও সরবরাহ করে checked_mulযেগুলি ওভারফ্লো হয়েছে কিনা তা পরীক্ষা করে এবং Noneযদি তা হয় তবে Someঅন্যথায় ফিরে আসে । এটি প্রোডাকশনের পাশাপাশি ডিবাগ মোডেও ব্যবহার করা যেতে পারে: doc.rust-lang.org/std/primitive.i32.html#example-15
আকাওয়াল

3

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

আরম্ভকারীরা কোলাটজ ক্রমটি মূল্যায়ন করার চেষ্টা করে এবং তাদের কোড ক্র্যাশ করেছে :-) দেখতে মজাদার

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

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


1
আমি মাঝে মাঝে ভেবে দেখেছি যে লোকেরা সি-তে ইউবি-চালিত পাগলিকে চাপ দিচ্ছে তারা যদি অন্য কোনও ভাষার পক্ষে গোপনে এটিকে ক্ষুণ্ন করার চেষ্টা করছিল কি না? এটা বোধগম্য হবে।
সুপারক্যাট

x+1>xনিঃশর্তভাবে সত্য হিসাবে চিকিত্সা করার জন্য x সম্পর্কে কোনও "অনুমান" করার জন্য কোনও সংকলক লাগবে না যদি কোনও সংকলক সুবিধামত আকারে বড় আকারের (বা এটি এমনটি করে যেমন আচরণ করে) ব্যবহার করে পূর্ণসংখ্যার এক্সপ্রেশনগুলি মূল্যায়নের অনুমতি দেয়। ওভারফ্লো-ভিত্তিক "অনুমান" এর একটি প্রাচীন উদাহরণ সিদ্ধান্ত গ্রহণ করবে যে uint32_t mul(uint16_t x, uint16_t y) { return x*y & 65535u; }একটি সংকলক প্রদত্ত sum += mul(65535, x)সিদ্ধান্তটি ব্যবহার করতে পারে যা x32768 এর চেয়ে বেশি হতে পারে না [আচরণটি সম্ভবত সি89 89 রেশনেল লিখেছেন এমন লোকদের স্তম্ভিত করবে, যা প্রস্তাবিত সিদ্ধান্তগুলির মধ্যে অন্যতম বলে মনে করে যে। ..
সুপারক্যাট

... unsigned shortপ্রচার করার ক্ষেত্রে signed intএই বিষয়টি ছিল যে দু'টির পরিপূরক নীরব-মোড়ক বাস্তবায়ন (অর্থাত সি এর বাস্তবায়নের সিংহভাগ) উল্লিখিত কোডের সাথে একইভাবে আচরণ করবে যেমন unsigned shortপ্রচারিত হোক intবা না হোক unsigned। উপরের মতো সানিলভাবে আচরণ করার জন্য স্ট্যান্ডার্ডটির নীরব-মোড়ক দুইটির পরিপূরক হার্ডওয়্যারের উপর প্রয়োগকরণের প্রয়োজন নেই , তবে স্ট্যান্ডার্ডটির লেখকরা প্রত্যাশা করেছেন যে তারা কোনওভাবেই এটি করতে চাইবে।
সুপারক্যাট

2

আসলে, এর আসল কারণটি বিশুদ্ধভাবে প্রযুক্তিগত / historicalতিহাসিক: সিপিইউর বেশিরভাগ অংশের জন্য উপেক্ষা চিহ্ন। সাধারণত রেজিস্টারগুলিতে দুটি পূর্ণসংখ্যার যোগ করার জন্য কেবলমাত্র একটি একক নির্দেশনা রয়েছে এবং আপনি এই দুটি পূর্ণসংখ্যাকে স্বাক্ষরিত বা স্বাক্ষরযুক্ত হিসাবে ব্যাখ্যা করেছেন কিনা সে বিষয়ে সিপিইউ কিছুটা চিন্তা করে না। একই বিয়োগ, এবং এমনকি গুণক জন্য। সাইন-সচেতন হওয়া দরকার একমাত্র গাণিতিক অপারেশনটি হ'ল বিভাগ।

এটি কেন কাজ করে তার কারণ হ'ল স্বাক্ষরিত পূর্ণসংখ্যার 2 এর পরিপূরক প্রতিনিধিত্ব যা কার্যত সমস্ত সিপিইউ ব্যবহার করে। উদাহরণস্বরূপ, 4-বিট 2 এর পরিপূরকটিতে 5 এবং -3 যোগটি এর মতো দেখায়:

  0101   (5)
  1101   (-3)
(11010)  (carry)
  ----
  0010   (2)

ক্যারি-আউট বিট ফেলে দেওয়ার মোড়কের চারপাশের আচরণ কীভাবে সঠিক স্বাক্ষরিত ফলাফল দেয় তা পর্যবেক্ষণ করুন। তেমনি, সিপিইউগুলি সাধারণত বিয়োগফলকে x - yএভাবে প্রয়োগ করে x + ~y + 1:

  0101   (5)
  1100   (~3, binary negation!)
(11011)  (carry, we carry in a 1 bit!)
  ----
  0010   (2)

এটি হার্ডওয়ারের সংযোজন হিসাবে বিয়োগফলকে কার্যকর করে, কেবলমাত্র গাণিতিক-লজিক্যাল-ইউনিট (এএলইউ) এর ক্ষুদ্রতর উপায়ে টুইট করে। সহজ কি হতে পারে?

যেহেতু গুণগুলি সংযোজনগুলির ক্রম ছাড়া আর কিছুই নয়, এটি একইভাবে দুর্দান্তভাবে আচরণ করে। 2 এর পরিপূরক প্রতিনিধিত্ব ব্যবহার এবং গাণিতিক ক্রিয়াকলাপগুলি সম্পাদন উপেক্ষা করার ফলাফলটি সরলিকৃত সার্কিটরি এবং সরল নির্দেশাবলীর সেট।

স্পষ্টতই, যেহেতু সি ধাতব ঘনিষ্ঠভাবে কাজ করার জন্য ডিজাইন করা হয়েছিল, তাই এটি স্বাক্ষরিত পাটিগণিতের মানসম্মত আচরণ হিসাবে এই ঠিক একই আচরণটি গ্রহণ করেছিল, কেবলমাত্র স্বাক্ষরিত পাটিগণিতকেই অপরিজ্ঞাত আচরণের সুযোগ দেয়। এবং এই পছন্দটি জাভা এবং স্পষ্টতই সি # এর মতো অন্যান্য ভাষায় নিয়ে গেছে।


আমি এই উত্তরটি দিতে এখানে এসেছি।
মিস্টার লিস্টার

দুর্ভাগ্যক্রমে, কিছু লোক মনে করে যে, একটি প্ল্যাটফর্মে নিম্ন-স্তরের সি কোড লেখার লোকদের এমন প্রত্যাশা করার মতো সাহস হওয়া উচিত যে এই ধরনের উদ্দেশ্যে উপযুক্ত সি সংকলক অতিরিক্ত প্রবাহের ক্ষেত্রে সীমাবদ্ধ ফ্যাশনে আচরণ করবে। ব্যক্তিগতভাবে, আমি কম্পাইলারের পক্ষে এটি আচরণ করা যুক্তিযুক্ত বলে মনে করি যদিও সংকলকটির সুবিধার্থে নির্বিচারে-বর্ধিত নির্ভুলতা ব্যবহার করে গণনা সম্পাদন করা হয় (সুতরাং 32-বিট সিস্টেমে যদি x==INT_MAX, তবে x+1নির্বিচারে সংযোজনকারীর মধ্যে +2147483648 বা -2147483648 হিসাবে আচরণ করা যেতে পারে সুবিধার্থে) তবে ...
সুপারক্যাট

কিছু কিছু মানুষের চিন্তা করতে যে যদি মনে xএবং yহয় uint16_tএবং একটি 32 বিট সিস্টেমে কোড নির্ণয় x*y & 65535uযখন y65535, একটি কম্পাইলার যে কোড অনুমান করা উচিত পৌঁছে করা হবে না যখন xচেয়ে 32768. বেশী
supercat

1

কিছু উত্তর চেক করার ব্যয় নিয়ে আলোচনা করেছে এবং আপনি বিতর্ক করার জন্য নিজের উত্তরটি সম্পাদনা করেছেন যে এটি যুক্তিসঙ্গত সমর্থনযোগ্যতা। আমি এই বিষয়গুলি সম্বোধন করার চেষ্টা করব।

সি এবং সি ++ (উদাহরণ হিসাবে) এর মধ্যে অন্যতম একটি ভাষা নকশার নীতিগুলি এমন কার্যকারিতা সরবরাহ করার জন্য নয় যা জিজ্ঞাসা করা হয়নি। এটি সাধারণত "আপনি যা ব্যবহার করেন না তার জন্য অর্থ প্রদান করবেন না" এই বাক্যটির সংক্ষিপ্তসার হয়। যদি প্রোগ্রামার ওভারফ্লো চেক করতে চায় তবে সে এটি চাইতে পারে (এবং জরিমানা দিতে হবে)। এটি ভাষাটি ব্যবহারে আরও বিপজ্জনক করে তোলে তবে আপনি এটি জেনে ভাষাটি নিয়ে কাজ করতে পছন্দ করেন, তাই আপনি ঝুঁকিটি গ্রহণ করেন। আপনি যদি সেই ঝুঁকি না চান, বা আপনি যদি সুর লিখছেন যেখানে সুরক্ষাই সর্বজনীন কর্মক্ষমতা, সেখানে আপনি আরও উপযুক্ত ভাষা বাছাই করতে পারেন যেখানে কর্মক্ষমতা / ঝুঁকি ট্রেডঅফ আলাদা।

তবে 10,000,000,000 পুনরাবৃত্তি সহ, একটি চেকের সময় নেওয়া এখনও 1 ন্যানোসেকেন্ডের চেয়ে কম।

এই যুক্তিটির সাথে কয়েকটি জিনিস ভুল রয়েছে:

  1. এটি পরিবেশ নির্দিষ্ট। এটি নির্দিষ্ট সুনির্দিষ্ট পরিসংখ্যানগুলি উদ্ধৃত করার পক্ষে খুব সামান্যই বোধগম্য হয়, কারণ কোডটি সমস্ত ধরণের পরিবেশের জন্য রচিত যা তাদের কর্মক্ষমতা অনুসারে আকারের আদেশ অনুসারে পরিবর্তিত হয়। একটি (আমার ধারনা) ডেস্কটপ মেশিনে থাকা আপনার 1 ন্যানোসেকেন্ডটি এম্বেডযুক্ত পরিবেশের জন্য কোডিং করা কাউকে আশ্চর্যরকম দ্রুত বলে মনে হতে পারে এবং সুপার কম্পিউটার ক্লাস্টারের জন্য কোডিং করা কেউ অসহনীয়ভাবে ধীর করে দেয়।

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

  3. কিছু অ্যালগরিদম এবং প্রসঙ্গে, 10,000,000,000 পুনরাবৃত্তি তুচ্ছ হতে পারে। আবার, নির্দিষ্ট পরিস্থিতিগুলির বিষয়ে কথা বলতে সাধারণত বুদ্ধি হয় না যা কেবলমাত্র কয়েকটি প্রসঙ্গে প্রযোজ্য।

এমন পরিস্থিতি থাকতে পারে যেখানে এটি গুরুত্বপূর্ণ, তবে বেশিরভাগ অ্যাপ্লিকেশনগুলির জন্য, এটি গুরুত্বপূর্ণ নয়।

সম্ভবত আপনি ঠিক বলেছেন। তবে আবার, এটি একটি নির্দিষ্ট ভাষার লক্ষ্যগুলি কী তা একটি বিষয়। অনেক ভাষা আসলে "সর্বাধিক" এর প্রয়োজনীয়তাগুলিকে সামঞ্জস্য করার জন্য বা অন্যান্য উদ্বেগগুলির তুলনায় সুরক্ষার পক্ষে করার জন্য ডিজাইন করা হয়। অন্যান্য, সি এবং সি ++ এর মতো দক্ষতার উপর অগ্রাধিকার দেয়। সেই প্রসঙ্গে, সবাইকে পারফরম্যান্সের জরিমানা প্রদান করা কেবলমাত্র কারণ বেশিরভাগ লোককে উদ্বিগ্ন করা হবে না, ভাষা যা অর্জন করার চেষ্টা করছে তার বিপরীতে।


-1

ভাল উত্তর আছে, কিন্তু আমি মনে করি এখানে একটি মিস পয়েন্ট আছে: একটি পূর্ণসংখ্যার ওভারফ্লো এর প্রভাবগুলি কোনও খারাপ জিনিস নয়, এবং বাস্তবতার পরে এটি জানা খুব কঠিন যে iঅস্তিত্বের MAX_INTসমস্যার MIN_INTকারণে কোনও অস্তিত্ব থেকে গেছে কিনা? অথবা যদি ইচ্ছাকৃতভাবে -1 দ্বারা গুণ করে করা হত।

উদাহরণস্বরূপ, আমি যদি 0 এর চেয়ে বেশি উপস্থাপনযোগ্য পূর্ণসংখ্যাগুলি একসাথে যোগ করতে চাই, আমি কেবল একটি for(i=0;i>=0;++i){...}সংযোজন লুপ ব্যবহার করব - এবং যখন এটি উপচে পড়ে এটি লক্ষ্যটি আচরণ করে (কোনও ত্রুটি ছুঁড়ে ফেলার অর্থ আমার অবরুদ্ধ হতে হবে) একটি স্বেচ্ছাসেবক সুরক্ষা কারণ এটি স্ট্যান্ডার্ড পাটিগণিতের সাথে হস্তক্ষেপ করছে। আদিমগণিতগুলিকে সীমাবদ্ধ করা খারাপ অভ্যাস, কারণ:

  • এগুলি সব কিছুতে ব্যবহৃত হয় - প্রতিটি কার্যকরী প্রোগ্রামে আদিম গণিতে একটি ধীরগতি
  • যদি কোনও প্রোগ্রামার তাদের প্রয়োজন হয় তবে তারা সর্বদা তাদের যুক্ত করতে পারে
  • আপনার যদি সেগুলি থাকে এবং প্রোগ্রামার তাদের প্রয়োজন না হয় (তবে দ্রুত রানটাইমের প্রয়োজন হয়) তবে তারা অপ্টিমাইজেশনের জন্য এগুলি সহজে সরাতে পারে না
  • আপনার যদি তাদের থাকে এবং প্রোগ্রামার তাদের সেখানে না থাকার প্রয়োজন হয় (যেমন উপরের উদাহরণে), প্রোগ্রামার উভয়ই রান-টাইম হিট নিচ্ছে (যা প্রাসঙ্গিক বা নাও হতে পারে), এবং প্রোগ্রামারটিকে এখনও অপসারণের জন্য সময় বিনিয়োগ করতে হবে বা 'সুরক্ষা' এর আশেপাশে কাজ করা।

3
কোনও প্রোগ্রামার যদি কোনও ভাষা এর জন্য সরবরাহ না করে তবে দক্ষ ওভারফ্লো চেকিং যুক্ত করা সত্যিই সম্ভব নয়। যদি কোনও ফাংশন কোনও মানটিকে উপেক্ষা করা হয় যা গণনা করে, একটি সংকলক গণনাটি অপ্টিমাইজ করতে পারে। যদি কোনও ফাংশন এমন কোনও মানকে গণনা করে যা ওভারফ্লো-চেকড তবে অন্যথায় উপেক্ষা করা হয়, একটি সংকলক অবশ্যই গণনা এবং ফাঁদটি সঞ্চালন করে যদি এটি ওভারফ্লো হয় তবে এমনকি যদি একটি ওভারফ্লো অন্যথায় প্রোগ্রামের আউটপুটকে প্রভাবিত না করে এবং নিরাপদে উপেক্ষা করা যায়।
সুপারক্যাট

1
আপনি এর থেকে যেতে পারে না INT_MAXকরার INT_MIN-1 দ্বারা গুন দ্বারা।
ডেভিড কনরাড

সমাধানটি অবশ্যই প্রোগ্রামারকে প্রদত্ত কোড বা সংকলন ইউনিটের একটি ব্লকে চেকগুলি বন্ধ করার জন্য একটি উপায় সরবরাহ করা।
ডেভিড কনরাড

for(i=0;i>=0;++i){...}আমি আমার দলে হতাশার চেষ্টা করার কোডটির স্টাইল: এটি বিশেষ প্রভাব / পার্শ্ব প্রতিক্রিয়াগুলির উপর নির্ভর করে এবং এটি কী বোঝাতে চাইছে তা স্পষ্টভাবে প্রকাশ করে না। তবে তবুও আমি আপনার উত্তরটির প্রশংসা করি কারণ এটি একটি ভিন্ন প্রোগ্রামিং প্যারাডিজাম দেখায়।
বার্নহার্ড হিলার

1
@ ডেলিওথ: যদি কোনও 64৪ i-বিট প্রকারের এমনকি সামঞ্জস্যপূর্ণ নীরব-মোড়কের দ্বার পরিপূরক আচরণের সাথে প্রয়োগ করা হয়, প্রতি সেকেন্ডে এক বিলিয়ন পুনরাবৃত্তি চালানো হয় তবে এই ধরণের লুপটি কেবলমাত্র সবচেয়ে বড় intমান খুঁজে পাওয়ার নিশ্চয়তা দিতে পারে যদি এটির জন্য চালানোর অনুমতি দেওয়া হয় তবে শত শত বছর ধরে. যে সিস্টেমে সামঞ্জস্যপূর্ণ নীরব-আবদ্ধ আচরণের প্রতিশ্রুতি দেওয়া হয় না, এই আচরণগুলি কতক্ষণ কোড দেওয়া হোক না কেন তার গ্যারান্টি দেওয়া হবে না।
সুপারক্যাট
আমাদের সাইট ব্যবহার করে, আপনি স্বীকার করেছেন যে আপনি আমাদের কুকি নীতি এবং গোপনীয়তা নীতিটি পড়েছেন এবং বুঝতে পেরেছেন ।
Licensed under cc by-sa 3.0 with attribution required.