सबूत कि मृत कोड संकलक द्वारा पता नहीं लगाया जा सकता है

Question

मैं अलग-अलग विषयों पर सर्दियों के पाठ्यक्रम को पढ़ाने की योजना बना रहा हूं, जिनमें से एक कंपाइलर होने जा रहा है। अब, मैं इस समस्या को पूरी तिमाही में देने के लिए असाइनमेंट्स के बारे में सोच रहा था, लेकिन इसने मुझे स्टम्प किया है इसलिए मैं इसे उदाहरण के रूप में उपयोग कर सकता हूं।

public class DeadCode {
  public static void main(String[] args) {
     return;
     System.out.println("This line won't print.");
  }
}

उपरोक्त कार्यक्रम में, यह स्पष्ट है कि प्रिंट स्टेटमेंट कभी भी निष्पादित नहीं होगा return। कंपाइलर कभी-कभी डेड कोड के बारे में चेतावनी या त्रुटियां देते हैं। उदाहरण के लिए, उपरोक्त कोड जावा में संकलित नहीं होगा। हालांकि, जावाक कंपाइलर हर प्रोग्राम में डेड कोड के सभी उदाहरणों का पता नहीं लगाएगा। मैं कैसे साबित करूंगा कि कोई भी कंपाइलर ऐसा नहीं कर सकता है।

Comments

आपकी पृष्ठभूमि क्या है और आप किस संदर्भ में पढ़ा रहे हैं? कुंद होने के लिए, मैं हल्के से चिंतित हूं कि आपको यह पूछना है, जैसा कि आप सिखाने जा रहे हैं। लेकिन यहाँ पूछ अच्छा है!

— राफेल

स्टैक ओवरफ्लो में एक ही सवाल

— मोयली

@ माइकलकॉर्जिंग डेड कोड का पता लगाना उन विचारों के बिना भी असंभव है।

— 20

BigInteger i = 0; while(isCollatzConjectureTrueFor(i)) i++; printf("Hello world\n");

— user253751

@immibis प्रश्न एक प्रमाण के लिए पूछता है कि मृत कोड का पता लगाना असंभव है । आपने एक उदाहरण दिया है जहां सही डेड कोड डिटेक्शन को गणित में एक खुली समस्या को हल करने की आवश्यकता होती है। यह साबित नहीं करता है कि मृत कोड का पता लगाना असंभव है ।

— डेविड रिचेर्बी

Answer 1

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

Run M on input x;
print "Finished running input";

यदि एम हमेशा के लिए चलता है, तो हम प्रिंट स्टेटमेंट को हटा देते हैं, क्योंकि हम कभी भी उस तक नहीं पहुंचेंगे। यदि M हमेशा के लिए नहीं चलता है, तो हमें प्रिंट स्टेटमेंट रखने की आवश्यकता है। इस प्रकार, यदि हमारे पास एक मृत-कोड पदच्युत है, तो यह हमें हॉल्टिंग समस्या को हल करने की भी सुविधा देता है, इसलिए हमें पता है कि ऐसा कोई मृत-कोड पदच्युत नहीं हो सकता है।

जिस तरह से हम इसके आस-पास पहुंचते हैं वह "रूढ़िवादी सन्निकटन" है। इसलिए, ऊपर मेरे ट्यूरिंग मशीन उदाहरण में, हम मान सकते हैं कि रनिंग एम ऑन एक्स खत्म हो सकता है, इसलिए हम इसे सुरक्षित खेलते हैं और प्रिंट स्टेटमेंट को नहीं हटाते हैं। आपके उदाहरण में, हम जानते हैं कि कोई भी कार्य नहीं करता है या रुकना नहीं है, इसका कोई तरीका नहीं है कि हम उस प्रिंट स्टेटमेंट तक पहुंचेंगे।

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

टिप्पणियों से कुछ भ्रम को स्पष्ट करने के लिए:

1. नाइटपिक: फिक्स्ड एम के लिए, यह हमेशा निर्णायक है। एम को इनपुट होना चाहिए

   जैसा कि राफेल कहते हैं, मेरे उदाहरण में, हम ट्यूरिंग मशीन को एक इनपुट मानते हैं। यह विचार है कि, अगर हमारे पास एक पूर्ण DCE एल्गोरिथ्म होता, तो हम किसी भी ट्यूरिंग मशीन के लिए दिए गए कोड स्निपेट का निर्माण करने में सक्षम होते , और DCE होने से हॉल्टिंग समस्या का समाधान होता।

2. आश्वस्त नहीं। नो-ब्रांच में ब्लंट स्टेटमेंट के रूप में लौटना सीधे आगे के निष्पादन के लिए तय करना मुश्किल नहीं है। (और मेरे संकलक ने मुझे बताया कि यह पता लगाने में सक्षम है)

   इस समस्या के लिए njzk2 उठता है: आप बिल्कुल सही हैं, इस मामले में आप यह निर्धारित कर सकते हैं कि वापसी के बाद एक बयान का कोई तरीका नहीं है। ऐसा इसलिए है क्योंकि यह काफी सरल है कि हम नियंत्रण-प्रवाह ग्राफ़ की कमी का उपयोग करके इसकी अप्रतिस्पर्धीता का वर्णन कर सकते हैं (अर्थात रिटर्न स्टेटमेंट में कोई आउटगोइंग एज नहीं हैं)। लेकिन कोई सही डेड कोड एलिमिनेटर नहीं है, जो सभी अप्रयुक्त कोड को समाप्त करता है।

3. मैं एक सबूत के लिए इनपुट-निर्भर प्रमाण नहीं लेता हूं। यदि इस तरह के उपयोगकर्ता इनपुट मौजूद हैं जो कोड को परिमित होने की अनुमति दे सकते हैं, तो यह संकलक के लिए सही है कि निम्नलिखित शाखा मृत नहीं है। मैं नहीं देख सकता कि ये सभी अपवोट किस लिए हैं, यह स्पष्ट (जैसे। अंतहीन स्टडिन) और गलत दोनों हैं।

   TomášZato के लिए: यह वास्तव में एक इनपुट निर्भर प्रमाण नहीं है। बल्कि, इसे "फोर्ल" के रूप में व्याख्या करें। यह निम्नानुसार काम करता है: मान लें कि हमारे पास एक पूर्ण DCE एल्गोरिथ्म है। यदि आप मुझे एक मनमाना ट्यूरिंग मशीन M और इनपुट x देते हैं, तो मैं अपने DCE एल्गोरिथ्म का उपयोग यह निर्धारित करने के लिए कर सकता हूं कि क्या M हाल्ट, ऊपर कोड स्निपेट का निर्माण करके और यह देखते हुए कि क्या प्रिंट-स्टेटमेंट हटा दिया गया है। फ़ोर-स्टेटमेंट को साबित करने के लिए एक पैरामीटर को मनमाने ढंग से छोड़ने की यह तकनीक, गणित और तर्क में सामान्य है।

   मैं पूरी तरह से TomášZato की बात को कोड के परिमित होने के बारे में नहीं समझता। निश्चित रूप से कोड परिमित है, लेकिन एक पूर्ण DCE एल्गोरिथ्म को सभी कोड पर लागू होना चाहिए, जो कि एक इन्फिनिटी सेट है। इसी तरह, जबकि कोड-ही फ़ाइन्ट है, इनपुट के संभावित सेट्स इनफिनिटी हैं, जैसा कि कोड का संभावित रनिंग-टाइम है।

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

इस तरह कोड पर विचार करें:

while (true)
  print "Hello"
print "goodbye"

स्पष्ट रूप से हम print "goodbye"कार्यक्रम के व्यवहार को बदलने के बिना निकाल सकते हैं । इस प्रकार, यह मृत कोड है। लेकिन वहाँ है कि अगर बजाय एक अलग समारोह कॉल (true)में whileहालत है, तो हम अगर हम इसे निकाल सकते हैं या नहीं कर सकते, undecidability के लिए अग्रणी पता नहीं है।

ध्यान दें कि मैं इसके साथ नहीं आ रहा हूं। यह संकलक के सिद्धांत में एक प्रसिद्ध परिणाम है। टाइगर बुक में इसकी चर्चा है । (आप यह देखने में सक्षम हो सकते हैं कि वे Google पुस्तकों में कहां बात करते हैं ।

Comments

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

— user2357112

यह उत्तर टिप्पणियों का संदर्भ देता है । जैसा कि मैंने उत्तर पढ़ा है, मुझे टिप्पणियों में कूदने की आवश्यकता है, फिर उत्तर पर वापस जाएं। यह भ्रामक है (दोगुना इसलिए जब आप समझते हैं कि टिप्पणियां नाजुक हैं और खो सकती हैं)। एक स्व-निहित उत्तर पढ़ना आसान होगा।

— टीआरआईजी

$n$$n$

$M$$x$$M$$x$

jmite, कृपया उत्तर में मान्य टिप्पणियों को शामिल करें ताकि उत्तर अपने आप खड़ा हो जाए। फिर सभी टिप्पणियों को ध्वजांकित करें जो अप्रचलित हैं ताकि हम सफाई कर सकें। धन्यवाद!

— राफेल

Answer 2

यह जेमाइट के जवाब पर एक मोड़ है जो गैर-समाप्ति के बारे में संभावित भ्रम को कम करता है। मैं एक ऐसा कार्यक्रम दूंगा जो हमेशा खुद को रोकता है, इसमें मृत कोड हो सकता है लेकिन हम (हमेशा) एल्गोरिथम को तय नहीं कर सकते हैं कि क्या यह है।

मृत कोड पहचानकर्ता के लिए इनपुट के निम्न वर्ग पर विचार करें:

simulateMx(n) {
  simulate TM M on input x for n steps
  if M did halt
    return 0
  else
    return 1
}

चूंकि Mऔर xतय किए गए हैं, अगर और केवल तभी रुकना नहीं है तो simulateMsमृत कोड है ।return 0Mx

$M$x$M$$M$

इसलिए, डेड-कोड की जाँच कम्प्यूटेबल नहीं है।

यदि आप इस संदर्भ में प्रमाण तकनीक के रूप में कमी से अपरिचित हैं, तो मैं हमारी संदर्भ सामग्री की सलाह देता हूं ।

Answer 3

विवरण में फंसने के बिना इस तरह की संपत्ति को प्रदर्शित करने का एक सरल तरीका निम्नलिखित लेम्मा का उपयोग करना है:

लेम्मा: ट्यूरिंग-पूर्ण भाषा के लिए किसी भी कंपाइलर सी के लिए, एक फ़ंक्शन मौजूद है undecidable_but_true()जो कोई तर्क नहीं लेता है और बूलियन को वापस लौटाता है, जैसे कि सी भविष्यवाणी नहीं कर सकता है कि क्या undecidable_but_true()सही या गलत रिटर्न देता है।

ध्यान दें कि फ़ंक्शन कंपाइलर पर निर्भर करता है। किसी फ़ंक्शन को देखते हुए undecidable_but_true1(), एक कंपाइलर को हमेशा इस ज्ञान के साथ संवर्धित किया जा सकता है कि यह फ़ंक्शन सही है या गलत; लेकिन हमेशा कुछ अन्य फ़ंक्शन undecidable_but_true2()होते हैं जिन्हें कवर नहीं किया जाएगा।

प्रमाण: राइस के प्रमेय द्वारा , संपत्ति "यह फ़ंक्शन सही है" अचूक है। इसलिए कोई भी स्थैतिक विश्लेषण एल्गोरिदम इस संपत्ति को सभी संभावित कार्यों के लिए तय करने में असमर्थ है।

कोरोलरी: एक कंपाइलर सी को देखते हुए, निम्न प्रोग्राम में डेड कोड होता है जिसका पता नहीं लगाया जा सकता है:

if (!undecidable_but_true()) {
    do_stuff();
}

---

जावा के बारे में एक नोट: जावा भाषा जनादेश देती है जो संकलक कुछ कार्यक्रमों को अस्वीकार कर देती है जिसमें पहुंच से बाहर कोड होता है, जबकि समझदारी से उस कोड को सभी उपलब्ध बिंदुओं पर प्रदान किया जाता है (जैसे गैर-शून्य फ़ंक्शन में नियंत्रण प्रवाह एक returnबयान के साथ समाप्त होना चाहिए )। भाषा बिल्कुल निर्दिष्ट करती है कि कैसे पहुंच योग्य कोड विश्लेषण किया जाता है; यदि ऐसा नहीं होता तो पोर्टेबल प्रोग्राम लिखना असंभव होगा। फार्म के एक कार्यक्रम को देखते हुए

some_method () {
    <code whose continuation is unreachable>
    // is throw InternalError() needed here?
}

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

String day_of_week(int n) {
    switch (n % 7) {
    case 0: return "Sunday";
    case 1: case -6: return "Monday";
    …
    case 6: case -1: return "Saturday";
    }
    // return or throw is required here, even though this point is unreachable
}

Comments

ध्यान दें कि कुछ भाषाओं के लिए कुछ संकलक यह पता लगाने में सक्षम हो सकते हैं कि इसका अंत day_of_weekअप्राप्य है।

— user253751

@immibis हाँ, उदाहरण के लिए CS101 छात्र इसे मेरे अनुभव में कर सकते हैं (हालांकि माना जाता है कि CS101 छात्र एक ध्वनि स्थैतिक विश्लेषक नहीं हैं, वे आमतौर पर नकारात्मक मामलों के बारे में भूल जाते हैं)। यह मेरी बात का हिस्सा है: यह अगम्य कोड के साथ एक प्रोग्राम का एक उदाहरण है जो एक जावा कंपाइलर का पता नहीं लगाएगा (कम से कम, इसके बारे में चेतावनी दे सकता है, लेकिन अस्वीकार नहीं कर सकता)।

— गिल्स एसओ- बुराई को रोकना '

मुझे डर है कि लेम्मा की चेतावनियाँ भ्रामक रूप से सबसे अच्छी तरह से गुमराह कर रही हैं। अनिश्चयता केवल तभी समझ में आती है जब आप इसे (अनंत) उदाहरणों के सेट के रूप में वाक्यांश देते हैं। (कंपाइलर प्रत्येक फ़ंक्शन के लिए एक उत्तर का उत्पादन करता है , और हम जानते हैं कि यह हमेशा सही नहीं हो सकता है, लेकिन यह कहना कि एक भी अवांछनीय उदाहरण बंद है।) लेम्मा और प्रूफ के बीच आपका पैराग्राफ (जो कि लेम्मा से काफी मेल नहीं खाता है। जैसा कि कहा गया है) इसे ठीक करने की कोशिश करता है, लेकिन मुझे लगता है कि स्पष्ट रूप से सही लेम्मा तैयार करना बेहतर होगा।

— राफेल

@ राफेल उह? नहीं, संकलक को इस सवाल का जवाब देने की आवश्यकता नहीं है कि "क्या यह फ़ंक्शन स्थिर है?"। वर्किंग कोड का निर्माण करने के लिए "मुझे नहीं पता" से इसे अलग करने की आवश्यकता नहीं है, लेकिन यह प्रासंगिक नहीं है क्योंकि हम केवल संकलक के स्थिर विश्लेषण भाग में रुचि रखते हैं, कोड अनुवाद भाग में नहीं। मुझे समझ नहीं आ रहा है कि आपको लेम्मा के कथन के बारे में क्या गुमराह या गलत लगता है - जब तक कि आपकी बात यह नहीं है कि मुझे "संकलक" के बजाय "स्थिर विश्लेषक" लिखना चाहिए?

— गिल्स एसओ- बुराई को रोकना '

कथन "अनिर्णयता" का अर्थ है कि एक उदाहरण है जो हल नहीं किया जा सकता है ", जो गलत है। (मैं आपको लगता है कि कहने के लिए मतलब नहीं पता है, लेकिन है कि यह कैसे, असावधान / novices के लिए पढ़ सकते हैं imho।)

— राफेल

Answer 4

जेमाइट का उत्तर इस बात पर लागू होता है कि क्या प्रोग्राम कभी गणना से बाहर निकलेगा - सिर्फ इसलिए कि यह अनंत है कि मैं मृत होने के बाद कोड को कॉल नहीं करूंगा।

हालाँकि, एक और दृष्टिकोण है: एक समस्या जिसके लिए एक उत्तर है, लेकिन यह अज्ञात है:

public void Demo()
{
  if (Chess.Evaluate(new Chessboard(), int.MaxValue) != 0)
    MessageBox.Show("Chess is unfair!");
  else
    MessageBox.Show("Chess is fair!");
}

public class chess
{
  public Int64 Evaluate(Chessboard Board, int SearchDepth)
  {
  ...
  }
}

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

विस्तृत रूप में:

Evaluate()यदि दोनों पक्ष पूरी तरह से (अधिकतम खोज गहराई के साथ) खेलते हैं, तो फ़ंक्शन गणना करता है कि कौन सा पक्ष शतरंज का खेल जीतता है।

शतरंज मूल्यांकनकर्ता आमतौर पर हर संभव कदम पर कुछ निर्दिष्ट गहराई से आगे देखते हैं और फिर उस बिंदु पर बोर्ड को स्कोर करने का प्रयास करते हैं (कभी-कभी कुछ शाखाओं को विनिमय के माध्यम से आधे रास्ते की तरह विस्तारित करते हुए या जैसे बहुत तिरछी धारणा पैदा कर सकते हैं।) वास्तविक अधिकतम गहराई के बाद से। 17695 अर्ध-चाल है खोज संपूर्ण है, यह हर संभव शतरंज खेल को पार कर जाएगी। चूंकि सभी खेल समाप्त होते हैं, इसलिए यह तय करने का कोई मुद्दा नहीं है कि प्रत्येक बोर्ड कितनी अच्छी स्थिति है (और इस तरह बोर्ड मूल्यांकन तर्क को देखने का कोई कारण नहीं है - इसे कभी नहीं कहा जाएगा), परिणाम या तो एक जीत है, एक हार या गैर नतीजा। यदि परिणाम ड्रॉ है तो खेल उचित है, यदि परिणाम ड्रॉ नहीं है तो यह एक अनुचित खेल है। इसे थोड़ा विस्तार करने के लिए हम प्राप्त करते हैं:

public Int64 Evaluate(Chessboard Board, int SearchDepth)
{
  foreach (ChessMove Move in Board.GetPossibleMoves())
    {
      Chessboard NewBoard = Board.MakeMove(Move);
      if (NewBoard.Checkmate()) return int.MaxValue;
      if (NewBoard.Draw()) return 0;
      if (SearchDepth == 0) return NewBoard.Score();
      return -Evaluate(NewBoard, SearchDepth - 1);
    }
}

ध्यान दें, यह भी कि यह संकलक के लिए लगभग असंभव हो जाएगा कि Chessboard.Score () मृत कोड है। शतरंज के नियमों का एक ज्ञान हमें मनुष्यों को यह पता लगाने की अनुमति देता है, लेकिन यह पता लगाने के लिए कि मेकमोव कभी भी टुकड़ा गिनती नहीं बढ़ा सकता है और यह कि शतरंजबोर्ड। () सही होगा यदि टुकड़ा गिनती बहुत लंबे समय तक स्थिर रहती है। ।

ध्यान दें कि खोज की गहराई आधी चालों में है, पूरी चालों में नहीं। यह इस तरह के एआई रूटीन के लिए सामान्य है क्योंकि यह एक ओ (एक्स ^ एन) रूटीन है - एक और खोज प्लाई को जोड़ने पर एक बड़ा प्रभाव पड़ता है कि इसे चलाने में कितना समय लगता है।

Comments

आप मानते हैं कि एक जाँच एल्गोरिथ्म को गणना करना होगा। एक आम गिरावट! नहीं, आपको इस बारे में कुछ भी ग्रहण करने की ज़रूरत नहीं है कि एक परीक्षक कैसे काम करेगा, अन्यथा आप इसके अस्तित्व का खंडन नहीं कर सकते।

— राफेल

प्रश्न एक प्रमाण का अनुरोध करता है कि मृत कोड का पता लगाना असंभव है। आपकी पोस्ट में एक ऐसे मामले का उदाहरण है जहां आपको संदेह है कि मृत कोड का पता लगाना मुश्किल होगा । यह सवाल का जवाब नहीं है।

— डेविड रिचेर्बी

@ लॉरेनप्लेट मुझे नहीं पता, लेकिन यह एक सबूत नहीं है। यहां भी देखें ; आपकी गलतफहमी का एक क्लीनर उदाहरण।

— राफेल

यदि यह मदद करता है, तो विचार करें कि सैद्धांतिक रूप से किसी को ब्रह्मांड के जीवनकाल से अधिक समय तक अपने संकलक को चलाने से रोकना नहीं है; केवल सीमा व्यावहारिकता है। एक विकट समस्या एक विकट समस्या है, भले ही यह जटिलता वर्ग NONELEMENTARY में हो।

— छद्म नाम

दूसरे शब्दों में, यह उत्तर सबसे अच्छा यह बताने के लिए है कि शायद यह संभव नहीं है कि एक संकलक का निर्माण करना आसान है जो सभी मृत कोड का पता लगाता है - लेकिन यह असंभवता का प्रमाण नहीं है। छात्रों के लिए अंतर्ज्ञान बनाने के तरीके के रूप में इस तरह का उदाहरण उपयोगी हो सकता है, लेकिन यह एक प्रमाण नहीं है। खुद को एक प्रमाण के रूप में पेश करके, यह एक असंतोष करता है। उत्तर को संपादित करने के लिए कहा जाना चाहिए कि यह एक अंतर्ज्ञान-निर्माण उदाहरण है, लेकिन असंभवता का प्रमाण नहीं है।

— डीडब्ल्यू

Answer 5

मुझे लगता है कि एक कंप्यूटिंग कोर्स में, संकलन समय और रन समय के बीच अंतर को समझने के संदर्भ में मृत कोड की धारणा दिलचस्प है!

एक कंपाइलर यह निर्धारित कर सकता है कि आपको कब कोड मिला है जो किसी भी संकलन-समय के परिदृश्य में नहीं हो सकता है, लेकिन यह रनटाइम के लिए ऐसा नहीं कर सकता है। लूप-ब्रेक टेस्ट के लिए उपयोगकर्ता इनपुट के साथ एक सरल समय-लूप दिखाता है कि।

यदि कोई संकलक वास्तव में रनटाइम डेड कोड निर्धारित कर सकता है (यानी पूर्ण ट्यूरिंग) तो एक तर्क है कि कोड को कभी भी चलाने की आवश्यकता नहीं है, क्योंकि नौकरी पहले से ही की गई है!

यदि और कुछ नहीं है, तो कोड-टाइम डेड कोड चेक पास करने वाला कोड का अस्तित्व इनपुट और सामान्य कोडिंग हाइजीन (वास्तविक परियोजनाओं की वास्तविक दुनिया में) पर व्यावहारिक सीमा-जाँच की आवश्यकता को दर्शाता है।

Comments

सवाल एक सबूत के लिए पूछता है कि मृत कोड का पता लगाना असंभव है। आपने उस प्रश्न का उत्तर नहीं दिया है।

— डेविड रिचरबी

इसके अलावा, आपका दावा है कि "एक कंपाइलर यह निर्धारित कर सकता है कि आपको कोड कब मिला है, जो किसी भी संकलन-समय परिदृश्य में कभी पता लगाया जा सकता है" गलत है और सीधे तौर पर विरोधाभासी है कि प्रश्न आपको क्या साबित करने के लिए कहता है।

— डेविड रिचेर्बी

@ डेविड रिचेर्बी, मुझे लगता है कि आप मुझे गलत समझ रहे होंगे। मैं सुझाव नहीं दे रहा हूं कि संकलन-समय की जाँच से सभी मृत कोड मिल सकते हैं, निश्चित रूप से नहीं। मैं सुझाव दे रहा हूं कि सभी मृत कोड के सेट का एक उपसमूह है जो संकलन समय पर विचार करने योग्य है। अगर मैं लिखता हूँ: if (true == false) {प्रिंट ("कुछ");}, वह प्रिंट स्टेटमेंट डेड कोड होने के लिए संकलन समय पर विवेकी होगा। क्या आप असहमत हैं कि यह आपके दावे का प्रतिवाद है?

— 15

ज़रूर, आप कुछ मृत कोड निर्धारित कर सकते हैं । लेकिन अगर आप बिना किसी योग्यता के "निर्धारित करें कि [जब आपके पास मृत कोड है]" कहने जा रहे हैं, तो मेरे लिए इसका मतलब है कि सभी मृत कोड खोजें, न कि केवल कुछ।

— डेविड रिचेर्बी