delphi कम्पाइलर हैंडल केस स्टेटमेंट कैसे करता है?




if-statement switch-statement (2)

मामले के बयान के तहत दस्तावेज में , यह कहते हैं:

केस लिस्ट द्वारा प्रस्तुत प्रत्येक मान केस स्टेटमेंट में अद्वितीय होना चाहिए;

और दिखाया गया उदाहरण,

case I of
  1..5: Caption := 'Low';
  6..9: Caption := 'High';
  0, 10..99: Caption := 'Out of range';
else
  Caption := ;
end

नेस्टेड सशर्त के बराबर है:

if I in [1..5] then
  Caption := 'Low';
else if I in [6..10] then
  Caption := 'High';
else if (I = 0) or (I in [10..99]) then
  Caption := 'Out of range'
else
  Caption := ;

तो पहली बोली से पता चलता है कि इसे एक सेट की तरह नियंत्रित किया जाता है ( यहां टिप्पणी पढ़िए, कम से कम एक व्यक्ति इस पर मेरे साथ है)

अब मैं हिस्सा जानता हूं

जहां चयनकर्ता अभिव्यक्ति 32 बीट्स से छोटे से एक ऑर्डिनल प्रकार की अभिव्यक्ति है

सेट के गुणों के साथ विरोधाभासी है क्योंकि इसे सेट के तहत उल्लेख किया गया है:

आधार प्रकार में 256 से अधिक संभव मूल्य नहीं हो सकते हैं, और उनके क्रमिकता 0 और 255 के बीच आती हैं

क्या वास्तव में मुझे गुस्सा दिलाना है यह है कि मामले की सूची में अद्वितीय मूल्यों की आवश्यकता क्यों है। यदि यह I स्टेटमेंट के समतुल्य है, if दूसरे मान का सिर्फ परीक्षण नहीं किया जाएगा क्योंकि कम्पाइलर पहले से ही एक पूर्व मैच मिला है?


मामला बयान
कंपाइलर मामले की बयान को एक जंप टेबल में बदलना पसंद करता है।
इस संभावित डुप्लिकेट केस लेबल को बनाने के लिए अनुमति नहीं है।

इसके अलावा, संकलक को उस केस के बयानों का परीक्षण करने की ज़रूरत नहीं है, जो आपने उन्हें घोषित कर दिया है। ऑप्टिमाइज़ेशन के कारणों से यह इन तत्वों को पुन: क्रमित करेगा जैसा कि यह उपयुक्त दिखता है; इसलिए भले ही यह एक छलांग टेबल का उपयोग न करे, फिर भी वह डुप्लिकेट केस लेबल को अनुमति नहीं दे सकता है।

यह इसी कारण के लिए है (और प्रोग्रामर को मानसिक रूप से समझने के लिए) कि मामले का बयान गिरावट की अनुमति नहीं देता है।

अगर कथन
ए (श्रृंखला) यदि बयान क्रम में संसाधित होते हैं तो उन्हें घोषित किया जाता है।
कंपाइलर उन्हें एक-एक करके जांच देगा (और जब उपयुक्त हो तो बाहर कूदो)।
अगर if-statement में डुप्लिकेट नहीं होते हैं, तो कोड समकक्ष केस स्टेटमेंट के समान होगा, लेकिन जनरेटेड कोड सबसे अधिक भिन्न होगा।
अगर बयान कभी कूद तालिकाओं में परिवर्तित नहीं किए जाते हैं

सेट के बारे में
कारण सेट 256 तत्वों तक सीमित होते हैं कि सेट में प्रत्येक तत्व एक बिट का स्थान लेता है।
256 बिट = 32 बाइट्स
एक सेट में 256 से ज्यादा तत्वों की अनुमति देने से स्मृति में प्रतिनिधित्व बहुत अधिक हो जाएगा, प्रदर्शन में बाधा उत्पन्न होगी।

मामले का विवरण सेट का उपयोग नहीं करता है, यह केवल इसके शब्दों में निर्धारित तर्क का उपयोग करता है।


दस्तावेज़ीकरण एक विशिष्ट केस स्टेटमेंट लेता है जो एक विशिष्ट अगर कथन के बराबर होता है।

सामान्य तौर पर, किसी भी मामले के बयान को एक ही दृष्टिकोण का उपयोग करते हुए एक बयान के रूप में फिर से लिखा जा सकता है। हालांकि, उलटा सही नहीं है

दस्तावेज एक समतुल्य का उपयोग करता है अगर कथन केस स्टेटमेंट के तार्किक व्यवहार (या अर्थ ) को समझाता है। यह कंपाइलर आंतरिक रूप से क्या करता है इसका एक प्रतिनिधित्व नहीं है

कम्पाइलर हैंडल कैस स्टेटमेंट कैसे करता है?

पहले ध्यान दें कि इस प्रश्न के 2 पहलू हैं।

  • सांप्रदायिक रूप से दस्तावेज में बताए गए अनुसार कम्पाइलर को केस स्टेटमेंट को संभालना होगा। यह भी शामिल है:
    • प्रत्येक केस लिस्ट प्रविष्टि के मूल्यों को सुनिश्चित करने के संकलन समय पर मूल्यांकन किया जा सकता है।
    • मामले की सूची सुनिश्चित करना अनन्य हैं।
    • जो भी मामला प्रविष्टि मेल खाता है, संबंधित केस-लिस्ट-स्टेटमेंट को कहा जाता है।
    • अगर कोई भी मामला लिस्ट प्रविष्टियां नहीं मिलती हैं, तो दूसरी बयानों को कहा जाता है
  • हालांकि, कंपाइलर कार्यान्वयन का अनुकूलन करने का हकदार है जैसा कि उपयुक्त दिखता है, अनुकूलित बाइट / मशीन कोड तार्किक रूप से समतुल्य है।
    • जोहान के जवाब में आम अनुकूलन का वर्णन है: जंप-सूचियां और क्रमबद्धता।
    • यह सख्त शब्दों को लागू करने के लिए बहुत आसान है I

क्या वास्तव में मुझे गुस्सा दिलाना है यह है कि मामले की सूची में अद्वितीय मूल्यों की आवश्यकता क्यों है।

अस्पष्टता को दूर करने के लिए विशिष्टता की आवश्यकता है यदि एक से अधिक मैचों में कौन सा कस्ट लिस्ट-स्टेटमेंट इस्तेमाल किया जाना चाहिए?

  • यह पहले मिलान वाले केस लिस्ट-स्टेटमेंट को कॉल कर सकता है और शेष को अनदेखा कर सकता है। (SQL सर्वर का CASE स्टेटमेंट इस तरह व्यवहार करता है।) नीचे देखें [1]
  • यह उन सभी को कह सकता है (अगर मुझे सही ढंग से याद है कि मैनिटिस प्रोग्रामिंग भाषा इस सिमेंटिक का उपयोग किसी केस स्टेटमेंट के संस्करण के लिए करती है।)
  • यह एक त्रुटि की रिपोर्ट कर सकता है जिससे प्रोग्रामर को मामले सूची को अलग-अलग करने की आवश्यकता हो । (सीधे शब्दों में कहें, डेल्फी के विनिर्देशों की आवश्यकता है। कई अन्य भाषाएं उसी दृष्टिकोण का उपयोग करती हैं। इसके बारे में चुप्पी बेजान हैं, खासकर जब से यह विकल्प बाधा के अधिक होने की संभावना नहीं है।)

अगर यह if स्टेटमेंट के बराबर है तो दूसरे मान का सिर्फ परीक्षण नहीं किया जाएगा क्योंकि कंपाइलर पहले से ही एक पूर्व मैच मिला है।

[1] मैं यह कहना चाहूंगा कि इससे कोड को पढ़ने में और अधिक कठिन हो सकता है जादू व्यवहार का उपयोग करते समय यह व्यवहार "ठीक है", लेकिन जब संय पहचानकर्ता का उपयोग करना खतरनाक हो जाता है यदि 2 अलग-अलग कोंडों का एक ही मान होता है, तो यह तुरंत स्पष्ट नहीं होगा कि बाद के मामले में लिखे गए वक्तव्य जहां केसलिस्ट भी मेल खाता नहीं होगा। इसके अलावा मामले के विवरण एक साधारण मामला पुन: आदेश देने के कारण व्यवहार परिवर्तन के अधीन होगा।

const
  NEW_CUSTOMER = 0;
  EDIT_CUSTOMER = 1;
  ...
  CANCEL_OPERATION = 0;

case UserAction of
  NEW_CUSTOMER : ...;
  EDIT_CUSTOMER : ...;
  ...
  CANCEL_OPERATION : ...; { Compiler error is very helpful. }
end;

सेट के गुणों के साथ विरोधाभासी

कोई विरोधाभास नहीं है तथ्य यह है कि प्रत्येक मुकदमे का मूल्य अद्वितीय होना चाहिए, किसी भी तरह से इसका मतलब नहीं है कि इसे "एक सेट की तरह नियंत्रित किया जाना चाहिए" यह आपकी गलत धारणा है वही धारणा करने वाले अन्य लोग भी गलत हैं।

कैसे विशिष्टता की बाधा जांच की गई है, संकलक पर निर्भर है। हम केवल अनुमान लगा सकते हैं लेकिन मुझे लगता था कि सबसे प्रभावी श्रेणी का क्रमबद्ध सूची बनाए रखना होगा। प्रत्येक मामले के माध्यम से काम करें मूल्यों और श्रेणियों की सूची, उपरोक्त सूची में अपनी स्थिति पाएं । यदि यह ओवरलैप हो, तो एक त्रुटि की रिपोर्ट करें, अन्यथा उसे सूची में जोड़ें





switch-statement