जब "अगर" और "जबकि" के साथ प्रयोग किया जाता है, तो भाषाओं को अभिव्यक्ति के आसपास कोष्ठक की आवश्यकता क्यों होती है?

Question

C, Java, और C ++ जैसी भाषाओं को जब , या में उपयोग किया जाता है if, तो संपूर्ण अभिव्यक्ति के आसपास कोष्ठक की आवश्यकता होती है ।whileswitch

if (true) {
    // Do something
}

विरोध के रूप में

if true {
    // Do something
}

यह मुझे अजीब लगता है क्योंकि कोष्ठक बेमानी है। इस उदाहरण में, trueअपने आप में एक एकल अभिव्यक्ति है। कोष्ठक किसी भी तरह से मेरे अर्थ को परिवर्तित नहीं करता है। यह विषम सिंटैक्स क्यों मौजूद है और यह इतना सामान्य क्यों है? क्या इसका कोई लाभ है जिसकी मुझे जानकारी नहीं है?

Comments

पास्कल को कोष्ठक की आवश्यकता नहीं है (क्योंकि इसके लिए आवश्यक है THEN)।

— जिमीबी

अजगर, रूबी नहीं।

— smci

मेरा मानना ​​है कि सी कोष्ठक का उपयोग करता है क्योंकि ब्रेस एकल-विवरण निकाय के लिए वैकल्पिक हैं। या शायद इसे लगाने का एक बेहतर तरीका यह है कि ब्रेसिज़ ifबयान का हिस्सा नहीं हैं , वे सिर्फ एक यौगिक बयान बनाते हैं।

— फ्रेड लार्सन

जाओ, दिलचस्प है, ब्रेसिज़ की आवश्यकता है लेकिन कोष्ठक नहीं।

— कोस

सवाल थोड़ा तल्ख है। गोल मैनहोल सभी गोल क्यों हैं? सभी भाई पुरुष क्यों हैं? पराग-आवश्यकता-भाषाएं सभी के लिए क्यों आवश्यक हैं? गोल मैनहोल कवर परिभाषा द्वारा गोल हैं; भाई परिभाषा से पुरुष हैं; जिन भाषाओं में parens की आवश्यकता होती है उन्हें परिभाषा के अनुसार parens की आवश्यकता होती है।

— एरिक लिपर्ट

Answer 1

यह बताने का कोई तरीका होना चाहिए कि स्थिति कहाँ समाप्त होती है और शाखा शुरू होती है। ऐसा करने के कई अलग-अलग तरीके हैं।

कुछ भाषाओं में, वहाँ कोई सशर्त हैं सब पर , जैसे स्मालटाक, स्व, Newspeak, Io, Ioke, Seph, और फैंसी में। सशर्त शाखाओं को किसी अन्य विधि की तरह सामान्य तरीके से लागू किया जाता है। विधि को बूलियन ऑब्जेक्ट्स पर लागू किया जाता है और बूलियन पर बुलाया जाता है। इस तरह, शर्त बस विधि का रिसीवर है, और दो शाखाएँ दो तर्क हैं, जैसे कि स्मालटाक में:

aBooleanExpression ifTrue: [23] ifFalse: [42].

मामले में, आप जावा से अधिक परिचित हैं, यह निम्नलिखित के बराबर है:

aBooleanExpression.ifThenElse(() -> 23, () -> 42);

भाषाओं के लिस्प परिवार में, स्थिति समान है: सशर्त केवल सामान्य कार्य हैं (वास्तव में, मैक्रोज़) और पहली तर्क स्थिति है, दूसरी और तीसरी तर्क शाखाएं हैं, इसलिए वे बस सामान्य फ़ंक्शन तर्क हैं, और वहाँ है उन्हें परिसीमित करने के लिए विशेष कुछ भी नहीं:

(if aBooleanExpression 23 42)

कुछ भाषाओं में सीमांकक के रूप में कीवर्ड का उपयोग किया जाता है, जैसे कि अल्गोल, अदा, बेसिक, पास्कल, मोडुला -2, ओबेरॉन, ओबेरॉन -2, सक्रिय ओबेरॉन, घटक पास्कल, ज़ोनॉन, मोडुला -3:

IF aBooleanExpression THEN RETURN 23 ELSE RETURN 42;

रूबी में, आप कीवर्ड या अभिव्यक्ति विभाजक (अर्धविराम या न्यूलाइन) का उपयोग कर सकते हैं:

if a_boolean_expression then 23 else 42 end

if a_boolean_expression; 23 else 42 end

# non-idiomatic, the minimum amount of whitespace required syntactically
if a_boolean_expression
23 else 42 end

# idiomatic, although only the first newline is required syntactically
if a_boolean_expression
  23
else
  42
end

गो को शाखाओं को ब्लॉक करने की आवश्यकता है और अभिव्यक्तियों या बयानों की अनुमति नहीं देता है, जो घुंघराले ब्रेस को अनिवार्य बनाता है। इसलिए, कोष्ठकों की आवश्यकता नहीं है, हालाँकि आप चाहें तो उन्हें जोड़ सकते हैं; Perl6 और Rust इस संबंध में समान हैं:

if aBooleanExpression { return 23 } else { return 42 }

कुछ भाषाएं अन्य गैर-अल्फ़ान्यूमेरिक वर्णों का उपयोग करके स्थिति को चित्रित करती हैं, जैसे कि पायथन:

if aBooleanExpression: return 23
else: return 42

लब्बोलुआब यह है: आपको यह बताने का कोई तरीका चाहिए कि स्थिति कहाँ समाप्त होती है और शाखा शुरू होती है। ऐसा करने के कई तरीके हैं, कोष्ठक उनमें से सिर्फ एक है।

Comments

बहुत अच्छा अवलोकन।

— पीटर ए। श्नाइडर

निश्चित रूप से ऐसी भाषा में, जहाँ या तो नंगे भावों का कथन नहीं है (जैसे कि पुराने BASIC जैसी कोई चीज़ जहाँ किसी परिकलित मान को या तो एक चर को सौंपा जाना चाहिए या किसी अन्य कथन को पास करना चाहिए) या जहाँ कोई उपसर्ग ऑपरेटर नहीं हैं, आपको हमेशा सक्षम होना चाहिए एक अभिव्यक्ति के अंत की पहचान करने के लिए और वैसे भी एक बयान की शुरुआत। मैं निश्चित रूप से एक IFIC के अंत में एक सीमांकक के बिना एक मूल संस्करण का प्रबंधन देख सकता था।

— पेरिआटा ब्रेटा

इसके अलावा, चूंकि सी 70 के दशक में डिज़ाइन किया गया था, और गणना महंगी थी, इसलिए थोड़ा कोष्ठक जोड़ना शायद पार्सर को लिखने के लिए थोड़ा आसान बना देगा।

— मचादो

पुन: लिस्प: "वास्तव में, मैक्रोज़"। व्यवहार में IF स्कीम और CL (सिर्फ पूर्णता के लिए) में एक विशेष रूप है।

— coredump

@ लुशेंको: और, जैसे कि एमआईएससी में, जो आलसी-डिफ़ॉल्ट रूप से है, सभी सशर्त रूप केवल सामान्य कार्य हैं, न तो मैक्रोज़ और न ही विशेष रूप। (वास्तव में, AFAIR, MISC के शून्य विशेष रूप हैं?)

— Jörg W Mittag

Answer 2

यदि आप ब्रेसिज़ का उपयोग करते हैं तो कोष्ठक केवल अनावश्यक हैं।

if true ++ x;

उदाहरण के लिए उनके बिना अस्पष्ट हो जाता है।

Comments

@RobertHarvey - कोष्ठक की आवश्यकता हर उस भाषा से होती है जिसके बारे में मैं जानता हूँ। निश्चित रूप से C और उसके परिजन। ओपी कारण है कि वे पूछ रहा है कर रहे हैं के लिए आवश्यक है - और यह क्योंकि भाषा अन्यथा अस्पष्ट बन जाएगा है।

— तेलस्टिन

बस मेरे सिर के ऊपर से, कोष्ठक के लिए आवश्यक नहीं हैं if: मूल, विधानसभा, अजगर, बाश / zsh, tcl, बैच, ब्रेनफक, या मशीन कोड। ifयदि भाषा को उन पर निर्भर करने के लिए डिज़ाइन किया गया है, तो लघुकोष्ठक का अभाव केवल एक अस्पष्ट बनाता है।

— कैंडिड_ओरेंज

Im हैरान था कि किसी ने सबसे तार्किक और पठनीय संस्करण का उल्लेख नहीं किया है - पास्कल (incl। डेल्फी) में if Condition then ...।

— उलरिच जेरहार्ट

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

— स्लीवेटमैन

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

— थियोडोरोस चटजिआनियाकिस

Answer 3

एक ifबयान में कोष्ठक का अर्थ वही नहीं है, जो अंकगणित में इस्तेमाल किया गया है। अंकगणितीय अभिव्यक्ति में कोष्ठक का उपयोग समूह के भावों को एक साथ करने के लिए किया जाता है। एक ifबयान में कोष्ठक का उपयोग बूलियन अभिव्यक्ति को चित्रित करने के लिए किया जाता है; यही है, बूलियन अभिव्यक्ति को बाकी ifबयान से अलग करना ।

एक ifबयान में, कोष्ठक एक समूहीकरण कार्य नहीं करते हैं (हालांकि, ifकथन के भीतर , आप अभी भी कोष्ठक का उपयोग समूह अंकगणितीय अभिव्यक्तियों में कर सकते हैं। कोष्ठकों का बाहरी सेट तब संपूर्ण बूलियन अभिव्यक्ति को परिसीमित करने का कार्य करता है)। उन्हें आवश्यक बनाना कंपाइलर को सरल बनाता है, क्योंकि कंपाइलर उन कोष्ठकों पर हमेशा भरोसा कर सकता है।

Comments

मैं यह नहीं देखता कि यह संकलक को कैसे सरल बनाता है। नियम `IF '(' अभिव्यक्ति ')' कथन 'से अधिक सरल नहीं है IF primary_expression statement। ध्यान दें कि उत्तरार्द्ध समान रूप से अस्पष्ट है।

— user58697

@ user58697: नहीं, केवल उत्तरार्द्ध में अस्पष्टता है जहां एक primary_expressionअभिव्यक्ति पर एक उपसर्ग ऑपरेटर से अभिव्यक्ति कथन पर भिन्न नहीं किया जा सकता है। Telastyn के जवाब कॉपी करने के if true ++ x;। इसके अलावा, यदि खाली स्टेटमेंट मौजूद हैं, if a & f;तो या तो स्टेटमेंट के &अंदर एक खाली स्टेटमेंट और बाइनरी हो सकता है, या &स्टेटमेंट की शुरुआत में एक यूनरी हो सकती है। लेकिन जब कोष्ठक से मेल खाते हैं, तो उद्घाटन के लिए बिल्कुल एक मैच होता है (

— MSalters

@ पोस्टर्स एक उपसर्ग ऑपरेटर प्राथमिक के रूप में पार्स नहीं करता है । एक प्राथमिक अभिव्यक्ति में से एक है IDENTIFIER, CONSTANT, STRING_LITERALऔर '(' expression ')'।

— user58697

@ user58697: आप एक विशेष भाषा को ध्यान में रखते हैं। और ऐसा प्रतीत होता है कि एक नियम है कि कोष्ठक की जरूरत नहीं है, केवल और अगर स्थितियां "IDENTIFIER, CONSTANT या STRING_LITERAL" हैं। मुझे यकीन नहीं है कि इससे चीजें आसान होंगी।

— MSALERS

Answer 4

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

if true
    +x;

क्योंकि इसकी व्याख्या इस प्रकार की जा सकती है:

if (true + x) {}

के बजाय:

if (true) {+x;}

कई भाषाएं (जैसे पायथन) आपको कोष्ठक से बचने की अनुमति देती हैं, लेकिन फिर भी एक अंतिम स्थिति होती है:

अगर सही : + x

लेकिन अगर आप सही है कि हम कर रहे हैं सकता है एक भाषा जहां एक अभिव्यक्ति है: एक भाषा जहां कोष्ठक आवश्यक कभी नहीं कर रहे हैं परिभाषित नहीं एक वैध बयान इस समस्या नहीं होगी।

दुर्भाग्य से इसका मतलब है कि चीजें:

 ++x;
 functionCall(1,2,3);

होता नहीं वैध बयान होना है, तो आप कुछ अजीब वाक्य रचना पेश करने का भाव बनाए बिना इस तरह के कार्यों को करने के लिए सक्षम होने के लिए होगा। इसका एक सरल तरीका यह है कि अभिव्यक्ति को केवल एक मार्कर द्वारा प्रस्तुत किया जाए जैसे [statement]:

[statement] ++x;
[statement] functionCall(1,2,3);

अब अस्पष्टता गायब हो जाती है क्योंकि आपको लिखना होगा:

if true
    [statement] ++x;

लेकिन जैसा कि आप देख सकते हैं कि मैं इस तरह की भाषा को व्यापक नहीं बनाता, क्योंकि कोष्ठक if(या :इसके अंत में) कोष्ठक के चारों ओर लगाने से बहुत बेहतर होता है और फिर प्रत्येक अभिव्यक्ति के लिए इस तरह के एक मार्कर को रखा जाता है।

---

नोट : एक [statement]मार्कर का उपयोग केवल सबसे सरल वाक्यविन्यास है जिसके बारे में मैं सोच सकता था। हालाँकि, आपके पास अभिव्यक्तियों और कथनों के लिए दो पूरी तरह से अलग वाक्यविन्यास हो सकते हैं जिनके बीच कोई अस्पष्टता नहीं है, जिसके लिए इस तरह के मार्कर की आवश्यकता नहीं होगी। समस्या यह है: भाषा बहुत ही अजीब होगी क्योंकि एक ही चीज़ को एक अभिव्यक्ति या एक कथन में करने के लिए आपको पूरी तरह से अलग वाक्यविन्यास का उपयोग करना होगा।

इस तरह के एक स्पष्ट मार्कर के बिना दो अलग-अलग वाक्यविन्यास करने के लिए दिमाग में आने वाली एक चीज होगी, उदाहरण के लिए: यूनिकोड प्रतीकों का उपयोग करने के लिए बयानों को बाध्य करें (इसलिए इसके बजाय forआप अक्षरों के कुछ यूनिकोड भिन्नता का उपयोग करेंगे f, oऔर r), जबकि अभिव्यक्ति होने के लिए। केवल ASCII।

Comments

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

— अमन

@amon अच्छा, मुझे उस बारे में पता नहीं था। वैसे भी, जैसा कि मैंने कहा कि मार्कर की वास्तव में आवश्यकता नहीं है, यह एक सरल तरीका है कि बिना किसी अनपेक्षित वाक्यविन्यास का आविष्कार किए बिना उस अंतर को प्राप्त किया जा सकता है।

— बाकूरी

@amon - कई मूल संस्करण भी अभिव्यक्तियों और कथनों के बीच एक सख्त अलगाव है। अभिव्यक्तियों को केवल उन स्थानों पर अनुमति दी जाती है जहां मूल्य वास्तव में उपयोग किया जाएगा (जैसे चर असाइनमेंट, PRINT जैसे कथन जो एक क्रिया करते हैं, और इसी तरह)। एक मूल्य की गणना करने के लिए जिन प्रक्रियाओं का उपयोग नहीं किया जाता है उन्हें एक कीवर्ड (आमतौर पर "CALL" द्वारा लागू किया जाता है, हालांकि कम से कम एक संस्करण जो मुझे "PROC" के उपयोग के बारे में पता है) जो उनके नाम को उपसर्ग करता है। और इसी तरह। बेसिक आमतौर पर "THEN" के साथ एक IF स्टेटमेंट में अभिव्यक्ति के अंत का परिसीमन करता है, लेकिन मैं ऐसा कोई तकनीकी कारण नहीं देख सकता जिसे आवश्यकता नहीं पड़ती।

— पेरिआटा ब्रीटाटा

80 के दशक में बहुत लोकप्रिय एक भाषा है जिसमें बिना परों, ब्रेसिज़, कॉलोन या किसी अन्य मार्कर के बिना ब्लॉक हैं और अभिव्यक्ति को हर जगह बयान के रूप में स्वीकार करते हैं और कुछ बयान अभिव्यक्ति (+ = और ++ जैसे यौगिक ऑपरेटरों) की तरह काम करते हैं। यह बिगड़ता है, संकलक से पहले एक डंब प्री-प्रोसेसर है ( ?उदाहरण के लिए वास्तव में पीपी के बाद एक फ़ंक्शन है)। नहीं है ;। निश्चित रूप से, इसे निरंतरता रेखा के लिए एक मार्कर की आवश्यकता होती है, लेकिन यह हतोत्साहित किया जाता है। harbour.github.io/doc/clc53.html#if-cmd । संकलक तेज और सरल है (बाइसन / फ्लेक्स के साथ बनाया गया है)।

— मनेरियो

@bigown वे तार्किक-स्थितियों के लिए एक अलग वाक्यविन्यास का उपयोग करके प्राप्त करते हैं, इसलिए, मूल रूप से, अन्य भाषाओं में उपयोग किए जाने वाले सामान्य अभिव्यक्तियों की तुलना में if, whileecc के लिए शर्तें सीमित हैं। सुनिश्चित करें: यदि आपके पास दो से अधिक वाक्यात्मक श्रेणियां हैं (जैसे कथन, अभिव्यक्ति, तार्किक-अभिव्यक्ति, कॉफी बनाने-अभिव्यक्ति, ...) आप कुछ स्वतंत्रता का व्यापार कर सकते हैं।

— बाकूरी

Answer 5

सी-परिवार की भाषाओं के लिए इन कोष्ठकों की आवश्यकता आम है, लेकिन सार्वभौमिक नहीं।

पर्ल 6 के अधिक ध्यान देने योग्य वाक्यगत परिवर्तनों में से एक यह है कि उन्होंने व्याकरण को संशोधित किया है ताकि आपको कोष्ठक के आसपास if, forऔर इसी तरह के बयानों की स्थिति न देनी पड़े । तो ऐसा कुछ पर्ल 6 में पूरी तरह से मान्य है:

if $x == 4 {
    ...
}

जैसा है

while $queue.pop {
    ...
}

हालाँकि, क्योंकि वे सिर्फ अभिव्यक्ति हैं, यदि आप चाहते हैं कि आप उनके चारों ओर कोष्ठक डाल सकते हैं, तो इस मामले में वे सिंटैक्स के आवश्यक भाग के बजाय साधारण समूह वाले हैं क्योंकि वे सी, सी #, जावा आदि में हैं।

जंग में इस विभाग में पर्ल 6 के समान सिंटैक्स है:

if x == 4 {
    ...
}

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

Comments

हालांकि आपका जवाब अन्य भाषाओं में कुछ अंतर्दृष्टि प्रदान करता है, लेकिन यह जवाब नहीं देता है "यह अजीब सिंटैक्स क्यों मौजूद है और यह इतना सामान्य क्यों है?"

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

— मैथ्यू वाल्टन

पर्ल 5 में दोनों है। BLOCKs के साथ एक सामान्य if या लूप निर्माण के लिए, Parens की आवश्यकता होती है, जैसे if ( $x == 4 ) { ... }या में foreach my $foo ( @bar ) { ... }। जब उपसर्ग संकेतन का उपयोग किया जाता है, तो parens वैकल्पिक होते हैं, जैसे कि return unless $foo;या में ++$x while s/foo/bar/g;।

— सिम्बैबेक

Answer 6

एक पहलू है जो मुझे आश्चर्य है कि मौजूदा जवाबों में से कोई भी नहीं लाया है।

सी, और कई सी डेरिवेटिव और लुक-एलाइक्स में एक ख़ासियत यह है कि असाइनमेंट का मूल्य निर्दिष्ट मूल्य है। इसका एक परिणाम यह है कि एक असाइनमेंट का उपयोग किया जा सकता है जहां एक मूल्य अपेक्षित है।

इससे आप जैसी चीजें लिख सकते हैं

if (x = getValue() == 42) { ... }

या

if (x == y = 47) { ... }

या

unsigned int n = 0 /* given m == SOME_VALUE */;
while (n < m && *p1++ = *p2++) { n++; }

(जो स्पष्ट रूप से माना जाता है while (n < m && *p1++ = *p2++ != 0) { n++; }क्योंकि सी गैर-शून्य को सच मानता है; संयोग से, मुझे लगता है कि सी मानक पुस्तकालय में केवल strncpy () के बारे में है)

या और भी

if (x = 17);

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

इस तरह के बयानों को पार्स करना कहीं अधिक कठिन होगा यदि यह निर्धारित करने के लिए कुछ स्पष्ट तरीका नहीं था कि सशर्त अभिव्यक्ति कहां से शुरू होती है और समाप्त होती है।

कोष्ठक पहले से ही फ़ंक्शन तर्कों से फ़ंक्शन नामों का परिसीमन करने के लिए उपयोग किया गया था, इसलिए मुझे लगता है कि वे एक प्राकृतिक विकल्प की तरह लग रहे थे कि कीवर्ड तर्कों से कीवर्ड को भी हटा दें।

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

कोष्ठक का उपयोग करना आज थोड़ा पुरातन लग सकता है, लेकिन ऐसा नहीं है कि भाषा के साथ किसी परिचित व्यक्ति को दिया जाता है, यह कुछ अन्य वाक्यविन्यास की तुलना में पठनीयता को प्रभावित करता है जो समान चीजों को व्यक्त करने में सक्षम है।

Answer 7

इसका कारण ज्यादातर इतिहास है।

उस समय जब पहला सी कंपाइलर लिखा गया था, कंप्यूटर में बहुत सीमित रैम, सीपीयू और कंपाइलर होते हैं, जहां कंपाइलर लेखकों की मदद के लिए कुछ उपकरणों के साथ "हाथ से" लिखा जाता है। इसलिए जटिल नियमों को एक संकलक में लागू करना महंगा था। C ++, C #, Java, आदि सभी को C प्रोग्रामर के लिए सीखना आसान बनाया गया था , इसलिए इसमें कोई "अनावश्यक" बदलाव नहीं किया गया था।

'सी लाइक' भाषाओं की शर्तों ( if, while, etc) में एक स्पष्ट blockऑफ कोड की आवश्यकता नहीं होती है , आप बस एक साधारण कथन का उपयोग कर सकते हैं।

if (a == d) doIt()

या आप compound statementउन्हें एक साथ डालकर बयानों को एक साथ जोड़ सकते हैं{}

हम संकलक को पसंद करते हैं कि हम जो त्रुटि करते हैं, वह हमें मिल जाए और त्रुटि संदेश के रूप में हम समझ सकें।

Answer 8

सी और एक बहुत ही लोकप्रिय प्रोग्रामिंग भाषा बन जाने के बाद जावा और सी ++ दोनों का विकास हुआ। उन भाषाओं में से प्रत्येक के डिजाइन में एक विचार यह था कि यह सी प्रोग्रामरों से अपील करेगा और उन प्रोग्रामर्स को नई भाषा का उपयोग करने के लिए लुभाने के लिए। (मैं सी प्रोग्रामर में से एक था जिसे उन्होंने सफलतापूर्वक मिटा दिया।) C ++ अतिरिक्त रूप से C कोड के साथ (लगभग) विनिमेय होने के लिए डिज़ाइन किया गया था। आदेश इन लक्ष्यों का समर्थन करने के लिए, दोनों सी ++ और जावा सी वाक्य रचना के बहुत, की शर्तों के आसपास कोष्ठक सहित अपनाया if, whileऔर switchबयान।

इसलिए इन सभी कथनों की शर्तों के आसपास इन सभी भाषाओं में कोष्ठकों की आवश्यकता होती है क्योंकि C करता है, और यह प्रश्न वास्तव में है कि C को उन कोष्ठकों की आवश्यकता क्यों है।

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

यह भी अनुमान लगाया जा सकता है कि कम वर्णों का उपयोग करके प्रोग्राम लिखने की क्षमता को एक लाभ माना जाता था, और दो कोष्ठक उस समय की तुलना THENमें फ़ोरट्रान और अन्य उच्च-स्तरीय भाषाओं में उपयोग किए जाने वाले कीवर्ड की तुलना में कम जगह लेते हैं ; वास्तव में, चूंकि कोष्ठक रिक्त स्थान को प्रतीकों के सीमांकक के रूप में बदल सकते हैं, इसलिए if(a==b)यह चार पूरे वर्णों से छोटा था IF a==b THEN।

किसी भी घटना में, सी में लिखे गए कार्यक्रमों को इंसान कितनी आसानी से पढ़, लिख और समझ पाएगा, इसके बीच कुछ संतुलन बनाना पड़ता था, कितनी आसानी से एक कंपाइलर सी में लिखे प्रोग्राम को पार्स और कंपाइल कर सकता था और कितने किलोबाइट (!) कर सकता था। कार्यक्रम स्रोत और संकलक दोनों के लिए आवश्यक होगा। और की शर्तों के आसपास कोष्ठक if, whileऔर switch बयान था कि लोग कैसे सी के डिजाइन में है कि संतुलन कायम करने के लिए चुना

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

Comments

मुझे यकीन नहीं है कि यह कहना उचित है कि सी ++ को "प्रोग्रामरों को लुभाने के लिए एक नई भाषा का उपयोग करने के लिए" जिस तरह से डिजाइन किया गया था। कक्षाओं के साथ सी याद रखें ?

— एक CVn

@ MichaelKjörling बेशक, जावा डेवलपर्स "लुभाने" के बारे में अधिक स्पष्ट थे। लेकिन ध्यान दें कि लिंक किए गए लेख का हवाला देते हैं, एक कारण के रूप में स्ट्रॉस्ट्रुप ने अपनी भाषा के आधार के रूप में सी के साथ शुरू करने के लिए चुना, उस सी का व्यापक रूप से उपयोग किया गया था। एक तरीका जिसमें इसने C के करीब रहने की प्रेरणा प्रदान की क्योंकि मौजूदा कोड को आसानी से अनुकूलित किया जा सकता था (जैसा कि मैंने पहले ही कहा था) - लेकिन मौजूदा कोडर भी आसानी से अनुकूलित कर सकते हैं।

— डेविड के

@ माइकलकॉग्लिंग मुझे लगता है कि मेरे उत्तर के मूल शब्द ने सुझाव दिया था कि "लुभाना" भाषा के डिजाइन का एक बड़ा कारक था, जो वास्तव में था। मैंने यह स्पष्ट करने के लिए उत्तर को संपादित किया है कि यह केवल एक चीज थी जो भाषा के डिजाइन में निहित थी।

— डेविड के

Answer 9

यहाँ कई कारण हैं कि बिना कोष्ठक के वाक्य रचना अस्पष्ट और चुपचाप होगी कि यह किसी तरह बुरा होगा या असंभव स्थिति भी होगी।

वास्तव में, भाषाओं में अस्पष्टताओं से निपटने के बहुत सारे तरीके हैं। संचालक पूर्वता इस विषय का सिर्फ एक उदाहरण है।

नहीं, अस्पष्टता कोष्ठकों का कारण नहीं है। मुझे लगता है कि कोई भी सी का एक संस्करण बना सकता है, जिसे स्थिति के आसपास कोष्ठकों की आवश्यकता नहीं है (इस प्रकार उन्हें वैकल्पिक बनाना) और जो अभी भी सभी मामलों में मान्य कोड बनाता है। के उदाहरण के if a ++ b;रूप में व्याख्या की जा सकती है if (a) ++b;या if (a++) b;, जो भी अधिक उपयुक्त लगता है, के बराबर है ।

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

और वास्तव में, सी को एक पास-पार्सर का उपयोग करके पार्स करने योग्य बनाया गया था। हालत के आसपास अनिवार्य कोष्ठकों के साथ एक वाक्यविन्यास का उपयोग करना इस पहलू का समर्थन करता है।

Comments

मैं अपने जवाब पर एक नीचा देखता हूं। कृपया एक टिप्पणी में यह समझाने की कृपा करें कि आपको इसके बारे में क्या पसंद नहीं आया। शायद मैं इसे तब सुधार सकता हूं।

— अल्फ

Answer 10

चारों ओर कोष्ठकों ifकी स्थिति फोरट्रान, कोबोल, पी एल / 1, अल्गोल, एल्गो-68, पास्कल, Modula, XPL, पी एल / एम, एमपीएल, ... या एक है कि किसी भी अन्य भाषा में की आवश्यकता नहीं है thenकीवर्ड। निम्नलिखित thenमें conditionसे परिसीमन करने का कार्य करता है statement।

सी आदि में समापन कोष्ठक के रूप में कार्य करता है then, और उद्घाटन एक औपचारिक रूप से बेमानी है।

उपरोक्त टिप्पणियां पारंपरिक रूप से पार्स भाषाओं पर लागू होती हैं।

Comments

फोरट्रान को स्ट्रक्चरल सहित अपने आईएफ के सभी संस्करणों में कोष्ठक की आवश्यकता होती है।

— नेट