2010-06-03 15 views
15

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

/* 
// 
// 
*/ 

लेकिन यदि आप पहले से ही एक/* एक वर्ग आप करना चाहते हैं में टिप्पणी है:

+6

"तथ्य"? वास्तव में? –

उत्तर

14

सी और सी ++ इसे पार्सिंग की आसानी के लिए करते हैं। इस तरह, जब उन्होंने/* की टिप्पणी शुरू की, तो पार्सर अंततः अंत तक स्कैन कर सकता है। अन्यथा, इसे एक स्टैक सेट अप और बनाए रखना होगा, और फिर टिप्पणी टोकन बेजोड़ होने पर त्रुटियों की रिपोर्ट करें।

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

+0

नेस्टेड टिप्पणियों को संभालने के लिए आपको स्टैक की आवश्यकता क्यों होगी? बस एक काउंटर बनाए रखें, हर बार जब आप '/ *' सामना करते हैं और इसे हर बार '*/'का सामना करते हैं तो इसे कम करते हैं। जब काउंटर शून्य से अधिक होता है तो आप किसी भी अक्षर को फेंक देते हैं (जबकि अभी भी '/ *' और '* /' का ट्रैक रखते हैं); जब काउंटर शून्य होता है तो आप सामान्य रूप से टोकन पढ़ते हैं और उन्हें पार्सर में सौंप देते हैं; यदि काउंटर नकारात्मक हो जाता है तो आप टिप्पणी डिलीमीटर के बीच एक मेल नहीं खाते की रिपोर्ट करते हैं। आप इसे व्याख्यात्मक विश्लेषण के दौरान करते हैं, इसलिए पार्सर कभी भी टिप्पणियां नहीं देखता है। –

3

अनुरूपता/सी

+1

सी नहीं मूल रूप से // टिप्पणी प्रतीक का उपयोग किया था? इसके अलावा, जावा को सी मानक के अनुरूप क्यों होना चाहिए? – tloach

+3

@ ट्लोच: '// 'सी 99 से पहले सी में मौजूद नहीं है। – kennytm

+7

सी मूल रूप से केवल * * */का उपयोग किया जाता था, और जावा को जानबूझकर सी (और सी ++) के बाद पैटर्न किया गया ताकि यह मौजूदा प्रोग्रामर से अधिक परिचित हो सके। कॉन्फॉर्म शायद यहां एक शब्द का बहुत मजबूत है, लेकिन मुझे यकीन नहीं है कि बेहतर क्या होगा। – ergosys

8

कम से कम ++ कि केवल आंशिक रूप से सच है सी के लिए के साथ संगतता, वहाँ के साथ कोई समस्या नहीं है टिप्पणी करें कि आप इसे #if 0 के साथ आसपास के आसपास कर सकते हैं जो मुझे लगता है कि कई कंपाइलर्स ऑप्टिमाइज़ हो जाते हैं। जैसा कि:

#if 0 
/* 

*/ 
#endif 
+1

सभी कंपाइलर्स इसे दूर ऑप्टिमाइज़ करते हैं, वैसे ही जब वे हेडर गार्ड का उपयोग करते हैं तो वे "ऑप्टिमाइज़" को एकाधिक में शामिल करते हैं, क्योंकि यह प्रीप्रोकैसिंग चरण का हिस्सा है। –

+4

कंपाइलर्स इस ब्लॉक को नहीं देख पाएंगे, * प्रीप्रोसेसर * इसे संकुचित कर देगा इससे पहले कि एक कंपाइलर कोड पर अपनी आंखें रखेगा :)। – Pieter

+0

@ वाह: हाँ, आप बिल्कुल सही हैं। मैं 'अगर (0)' के बारे में सोच रहा था जो मुझे लगता है कि संकलक निर्भर है। –

3

यह प्रत्येक भाषा (-फैमिली) के लिए अलग है लेकिन आम तौर पर वे 'वर्जित' नहीं हैं बल्कि बस समर्थित नहीं हैं। उनका समर्थन करना एक डिजाइन विकल्प है।

पसंद के लिए एक कारण (पुरानी भाषाओं के लिए) पार्सिंग में आसानी हो सकती है।

नोट: मुझे एक सी ++ कंपाइलर याद है जहां यह उन्हें घोंसला देने का विकल्प था। इसे 'गैर मानक' के रूप में चिह्नित किया गया था।

/* This is a comment /* Nested Comments */ are not allowed. */ 

कुछ भी जो /* और */ के बीच स्थित एक टिप्पणी के रूप में व्यवहार किया जाता है:

2

निम्न उदाहरण पर विचार करें। उपरोक्त उदाहरण में This से Comments तक सब कुछ /* सहित टिप्पणियों के रूप में माना जाता है। इसलिए, are not allowed. */ टिप्पणी में झूठ नहीं बोलता है। यह एक अनुचित सी कथन त्रुटि होती है।

हालांकि इस उदाहरण पर विचार करें:

// This is an /* valid */ comment 

जो भी लाइन में निहित है के बाद // टिप्पणी के रूप में व्यवहार किया जाता है। चूंकि /* valid */// के बाद एक ही पंक्ति में स्थित है, इसलिए इसे टिप्पणी का हिस्सा माना जाता है।

0

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

यदि कोई स्क्रैच से एक भाषा तैयार कर रहा था, तो एक अच्छा दृष्टिकोण प्रारंभिक टिप्पणी और अंत-टिप्पणी वाले अंक निर्दिष्ट करना हो सकता है जिसमें वैकल्पिक स्ट्रिंग शामिल है, और भाषा एक आवश्यकता को लागू करती है जिसमें स्ट्रिंग एंड-ऑफ-टिप्पणी चिह्न स्ट्रिंग से इसके संबंधित प्रारंभ-टिप्पणी-चिह्न चिह्न से मेल खाना चाहिए। वाक्यविन्यास मानना ​​<|String| और |String|> था, तब एक कंपाइलर <|1| <|2| |2|> |1|> स्वीकार कर सकता था, लेकिन <|1| <|2| |1|> |2|> को अस्वीकार कर सकता था। यहां तक ​​कि अगर किसी ने टिप्पणियों के बजाए #if निर्देशों के उपयोग का पक्ष लिया है, तो यह सुनिश्चित करने के लिए मार्करों को संलग्न करने की क्षमता है कि प्रत्येक अंतिम निर्देश उद्देश्य से शुरू किए गए निर्देश के साथ मेल खाता है।

-1

समस्या यह है कि आप केवल ब्लॉक को "छोड़ नहीं सकते"। ब्लॉक में उनके अंदर ब्लॉक की अज्ञात संख्या है, इसलिए यह जानने के लिए कि वह ब्लॉक कब पूरा हो गया है, आप नियमित भाषा का उपयोग नहीं कर सकते हैं, आपको स्टैक का उपयोग करना होगा और प्रत्येक ब्लॉक के माध्यम से स्टैक खाली होने तक चलना होगा, जिस बिंदु पर आप जानते हैं कि ब्लॉक किया गया है।

कारण आप ब्लॉक को छोड़ नहीं सकते हैं यह है कि ब्लॉक के लिए नियमित अभिव्यक्ति केवल * पहले */इसे बाद में देखे जाने वाले "या" आखिरी */बाद में देखे जाने वाले "के साथ मिलान करने में सक्षम है। या "एनएच */यह बाद में देखता है"।

अगर हम पहले "* /" टोकन हम देखते हैं के साथ जाना है, हम कोड की तरह

/* 
    /* 

    */ 
    the compiler matched /* with */ and this line and the next one will confuse it. 
*/ 

अगर हम पिछले "* /" टोकन हम देखते हैं के साथ जाने के लिए हो सकता है, हम कोड है जहां संकलक फ़ाइल में पहली टिप्पणी और फ़ाइल के अंत की अंतिम टिप्पणी के बीच चीजों को छोड़ देगा। इस मामले में, निम्न कोड को खाली स्ट्रिंग के रूप में पार्स किया जाएगा।

/* 
    /* hello, world! */ 
*/ 
int main(int argc, char ** argv) { 
    return 0; 
} 
/* end of file */ 

हम छोड़ n सभी टिप्पणियों के लिए मजबूर कर गहराई की सही संख्या के लिए बिना भीतरी ब्लॉक के तीसरे विकल्प के साथ नहीं जा सकते, अन्यथा यह आंतरिक टिप्पणी नहीं मिल रहा और उलझन में मिल जाएगा।

दरअसल, स्पष्ट रूप से यह कहने का एक चौथा विकल्प है कि एक टिप्पणी एक टिप्पणी हो सकती है, 2-स्कोप टिप्पणी, 3-स्कोप टिप्पणी आदि; लेकिन ऐसा करना एक बदसूरत है, और गहराई के प्रत्येक स्तर की एक लंबी अवधि की अभिव्यक्ति की आवश्यकता होती है, और यह दृष्टिकोण एक विशिष्ट गहराई को टिप्पणियों को सीमित करता है जो कुछ लोगों को फिट कर सकता है, और दूसरों के अनुरूप नहीं हो सकता है: क्या होगा यदि आप उस कोड को टिप्पणी करते हैं जिस पर टिप्पणी की गई है 3 बार?

<?php 
function stripComments($code) { 
    $stack = array(); 
    $codeOut = ''; 
    $stringStream = fopen('php://memory', 'r+'); 
    fwrite($stringStream, $code); 
    rewind($stringStream); 

    while (!feof($stringStream)) { 
     $ch = fgetc($stringStream); 

     $nextChar = fgetc($stringStream); 
     if ($nextChar === false) { 
      break; 
     } 

     if ($ch == '/' && $nextChar == '*') { 
      array_push($stack, '/*');   
     } else if ($ch == '*' && $nextChar == '/') { 
      if (count($stack) > 0) { 
       array_pop($stack); 
      } else { 
       die('cannot pop from empty stack'); 
      } 
     } else { 
      if (count($stack) == 0) { 
       $codeOut .= $ch; 
       fseek($stringStream, -1, SEEK_CUR); 
      } 
     }    

     $prevChar = $ch; 
    } 
    return $codeOut; 
}; 
?> 

कौन क्या सी वर्तमान में उपयोग करता है की तुलना में थोड़ा अधिक जटिल है:

function stripComments($code) { 
    return preg_replace('/\/\*[^\*\/]*\*\//', '', $code); 
} 

यह विचार /**/ पर ध्यान नहीं देता

सामान्य समाधान एक पूर्व पूर्वप्रक्रमक जैसे के साथ लागू किया जा सकता कोट्स के अंदर ब्लॉक, थोड़ा और जटिल स्टैक जो "/ *" स्कोप और "\" "के बीच अंतर कर सकता है"

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

सारांश: यह किया जा सकता है, लेकिन अधिकांश भाषाएं टिप्पणियों का इलाज नहीं करना चाहती हैं जैसे कि वे अपने स्वयं के क्षेत्र थे, क्योंकि यह पार्स करने के लिए और अधिक प्रयास करता है।