हमें स्विच में ब्रेक का उपयोग क्यों करना है?

Question

किसने तय किया (और किन अवधारणाओं के आधार पर) उस switchनिर्माण (कई भाषाओं में) breakप्रत्येक कथन में उपयोग करना है?

हमें ऐसा कुछ क्यों लिखना है:

switch(a)
{
    case 1:
        result = 'one';
        break;
    case 2:
        result = 'two';
        break;
    default:
        result = 'not determined';
        break;
}

(PHP और JS में इस पर ध्यान दिया गया है; इस का उपयोग करने वाली संभवतः कई अन्य भाषाएँ हैं)

यदि switchइसका एक विकल्प है if, तो हम उसी निर्माण का उपयोग क्यों नहीं कर सकते हैं if? अर्थात:

switch(a)
{
    case 1:
    {
        result = 'one';
    }
    case 2:
    {
        result = 'two';
    }
    default:
    {
        result = 'not determined';
    }
}

यह कहा जाता है कि breakवर्तमान के बाद ब्लॉक के निष्पादन को रोकता है। लेकिन, क्या कोई व्यक्ति वास्तव में उस स्थिति में भागता है, जहां मौजूदा ब्लॉक के निष्पादन और उसके बाद वाले लोगों की जरूरत थी? मैंने नहीं किया। मेरे लिए, breakहमेशा से है। हर ब्लॉक में। हर कोड में।

Comments

जैसा कि अधिकांश उत्तरों ने उल्लेख किया है, यह 'फॉल-थ्रू' से संबंधित है, जहाँ एक ही 'ब्लॉक' के माध्यम से कई स्थितियों को रूट किया जाता है। हालांकि, यह भाषा पर निर्भर है - आरपीजी, उदाहरण के लिए, एक CASEबयान को एक विशाल के बराबर मानता है यदि / फारस ब्लॉक।

— क्लॉकवर्क-म्यूजियम

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

— ब्लूराजा - डैनी Pflughoeft

मैंने कई मौकों पर फॉल-थ्रू का उपयोग किया है, हालांकि समय के साथ मेरी पसंदीदा भाषा में स्विच स्टेटमेंट (सी) को इससे बचने के लिए डिज़ाइन किया जा सकता था; उदाहरण के लिए मैंने किया है case 'a': case 'A': case 'b': case 'B'लेकिन ज्यादातर क्योंकि मैं नहीं कर सकता case in [ 'a', 'A', 'b', 'B' ]। थोड़ा बेहतर सवाल यह है कि, मेरी वर्तमान पसंदीदा भाषा (C #) में, ब्रेक अनिवार्य है , और कोई अंतर्निहित गिरावट नहीं है , हालांकि; भूल breakमें सिंटेक्स त्रुटि है ...: \

— KutuluMike

वास्तविक कोड के साथ फ़ॉल-थ्रू अक्सर पार्सर कार्यान्वयन में पाया जाता है। case TOKEN_A: /*set flag*/; case TOKEN_B: /*consume token*/; break; case TOKEN_C: /*...*/

— ऑरेंजडॉग

@ BlueRaja-DannyPflughoeft: C को भी संकलन करने के लिए आसान बनाया गया था। " breakकहीं भी मौजूद होने पर कूदना छोड़ें " को लागू करने के लिए एक बहुत ही सरल नियम है "अगर इसमें fallthroughमौजूद है तो छलांग न लगाएं switch"।

— जॉन पर्पडी

Answer 1

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

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

इसलिए मूल रूप से, C के डिजाइनरों ने असेंबलर शब्दार्थ प्रति डिफ़ॉल्ट रखने के लिए भी चुना।

Comments

VB.NET उस भाषा का उदाहरण है जिसने इसे बदल दिया। केस क्लॉज में प्रवाहित होने का कोई खतरा नहीं है।

— पोक

Tcl की एक और भाषा जो अगले खंड के माध्यम से कभी नहीं गिरती है। वस्तुतः कभी भी ऐसा नहीं करना चाहता था (सी के विपरीत जहां कुछ प्रकार के कार्यक्रम लिखते समय यह उपयोगी होता है)।

— डोना फेलो

C की पूर्वज भाषा, B और पुरानी BCPL , दोनों में (है?) स्विच स्टेटमेंट हैं; बीसीपीएल ने इसे वर्तनी दिया switchon।

— कीथ थॉम्पसन

रूबी के मामले के बयान के माध्यम से गिर नहीं है; आप एक एकल में दो परीक्षण मान रखकर समान व्यवहार प्राप्त कर सकते हैं when।

— नाथन लॉन्ग

Answer 2

क्योंकि उन भाषाओं में बयान switchका कोई विकल्प नहीं है if ... else।

उपयोग करके switch, हम एक समय में एक से अधिक स्थितियों से मेल खा सकते हैं, जो कुछ मामलों में बहुत सराहना की जाती है।

उदाहरण:

public Season SeasonFromMonth(Month month)
{
    Season season;
    switch (month)
    {
        case Month.December:
        case Month.January:
        case Month.February:
            season = Season.Winter;
            break;

        case Month.March:
        case Month.April:
        case Month.May:
            season = Season.Spring;
            break;

        case Month.June:
        case Month.July:
        case Month.August:
            season = Season.Summer;
            break;

        default:
            season = Season.Autumn;
            break;
    }

    return season;
}

Comments

more than one block ... unwanted in most casesमैं आपसे सहमत नहीं हूँ।

— सतीश पांडे

@DanielB यह भाषा पर निर्भर करता है; C # स्विच स्टेटमेंट उस अधिभोग के लिए अनुमति नहीं देते हैं।

— एंडी

@ और क्या हम अभी भी गिरावट के बारे में बात कर रहे हैं? सी # स्विच स्टेटमेंट निश्चित रूप से इसके लिए अनुमति देते हैं (3 उदाहरण की जांच करें), इसलिए इसकी आवश्यकता है break। लेकिन हाँ, जहाँ तक मेरी जानकारी है, Duff का डिवाइस C # में काम नहीं करता है।

— डैनियल बी

@DanielB हम हैं, लेकिन संकलक एक शर्त, कोड, और फिर एक और शर्त को बिना विराम के अनुमति नहीं देगा। आपके पास बिना किसी कोड के स्टैक किए गए उत्परिवर्ती स्थितियां हो सकती हैं, या आपको एक ब्रेक की आवश्यकता है। अपने लिंक से C# does not support an implicit fall through from one case label to another। आप इसके माध्यम से गिर सकते हैं, लेकिन आकस्मिक रूप से एक ब्रेक को भूलने का कोई मौका नहीं है।

— एंडी

@ मात्सेमन्न .. मैं अब हम सभी सामान का उपयोग कर सकते हैं if..elseलेकिन कुछ स्थितियों switch..caseमें बेहतर होगा। उपरोक्त उदाहरण थोड़ा जटिल होगा यदि हम if-else का उपयोग करते हैं।

— सतीश पांडेय

Answer 3

सी के संदर्भ में स्टैक ओवरफ्लो पर यह पूछा गया है: स्विच स्टेटमेंट को ब्रेक की आवश्यकता के लिए क्यों बनाया गया था?

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

Comments

Google Go वही काम करता है जो IIRC करता है (यदि स्पष्ट रूप से निर्दिष्ट किया जाता है तो अनुमति देता है)।

— सिंह

PHP भी करता है। और जितना अधिक आप परिणामी कोड को देखते हैं, उतनी असहजता आपको महसूस होती है। मुझे /* FALLTHRU */@Tapio द्वारा दिए गए उत्तर में टिप्पणी पसंद है , आपको यह साबित करने के लिए ।

— डेवप

C # के पास goto case, जैसा कि लिंक करता है, यह नहीं बताता कि यह इतनी अच्छी तरह से क्यों काम करता है। आप अभी भी ऊपर की तरह कई मामलों को ढेर कर सकते हैं, लेकिन जैसे ही आप कोड goto case whateverडालते हैं, आपको अगले मामले में गिरने के लिए स्पष्ट होना होगा या आपको एक कंपाइलर इरोर मिलेगा। यदि आप मुझसे पूछें, दो में से, लापरवाही के माध्यम से अनजाने में गिरावट के बारे में चिंता किए बिना मामलों को ढेर करने की क्षमता स्पष्ट गिरावट के माध्यम से सक्षम करने की तुलना में कहीं बेहतर सुविधा है goto case।

— जेसपर

Answer 4

मैं एक उदाहरण के साथ उत्तर दूंगा। यदि आप वर्ष के प्रत्येक महीने के दिनों की संख्या को सूचीबद्ध करना चाहते हैं, तो यह स्पष्ट है कि कुछ महीनों में 31, कुछ 30 और 1 28/29 हैं। यह इस तरह दिखेगा,

switch(month) {
    case 4:
    case 6:
    case 9:
    case 11;
        days = 30;
        break;
    case 2:
        //Find out if is leap year( divisible by 4 and all that other stuff)
        days = 28 or 29;
        break;
    default:
        days = 31;
}

यह एक उदाहरण है जहां कई मामलों का समान प्रभाव होता है और सभी एक साथ समूहीकृत होते हैं। स्पष्ट रूप से ब्रेक कीवर्ड की पसंद का एक कारण था और यदि नहीं तो ... और अगर निर्माण।

यहां ध्यान देने वाली मुख्य बात यह है कि कई समान मामलों के साथ एक स्विच स्टेटमेंट एक नहीं है ... और यदि ... और तो और ... मामलों में से प्रत्येक के लिए, बल्कि यदि (1, 2, 3) ... और अगर (4,5,6) और ...

Comments

आपका उदाहरण ifबिना किसी लाभ के अधिक क्रियात्मक दिखता है । शायद अगर आपके उदाहरण में एक नाम दिया गया है या गिरावट के माध्यम से महीने-विशिष्ट काम किया गया है, तो गिरावट के माध्यम से उपयोगिता अधिक स्पष्ट होगी? (पहली जगह में एक

— SHOULD

यह सच है। मैं हालांकि केवल उन मामलों को दिखाने का प्रयास कर रहा था, जिनके माध्यम से गिरावट का उपयोग किया जा सकता है। यह स्पष्ट रूप से बेहतर होगा यदि प्रत्येक महीने को व्यक्तिगत रूप से कुछ करने की आवश्यकता है।

— अवीमो

Answer 5

ऐसी दो स्थितियाँ हैं जहाँ "एक मामले से दूसरे में गिरना" हो सकता है - खाली मामला:

switch ( ... )
{
  case 1:
  case 2:
    do_something_for_1_and_2();
    break;
  ...
}

और गैर-खाली मामला

switch ( ... )
{
  case 1:
    do_something_for_1();
    /* Deliberately fall through */
  case 2:
    do_something_for_1_and_2();
    break;
...
}

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

पूर्व पूरी तरह से समझदार और आम है।

ईमानदार होने के लिए, मुझे breakऔर भाषा पार्सर को यह जानने के लिए कोई कारण नहीं दिखाई दे सकता है कि खाली केस-बॉडी एक गिरावट है, जबकि एक गैर-खाली मामला स्टैंडअलोन है।

यह अफ़सोस की बात है कि ISO C पैनल भाषा को नई (अवांछित) और बुरी तरह से परिभाषित सुविधाओं के साथ जोड़ने में अधिक व्यस्त लगता है, न कि अपरिभाषित का उल्लेख करने के लिए अपरिभाषित, अनिर्दिष्ट या कार्यान्वयन-परिभाषित सुविधाओं को ठीक करने के बजाय।

Comments

भाषा में परिवर्तन को शुरू करने में आईएसओ सी अच्छाई का धन्यवाद नहीं है!

— जैक आइडली

Answer 6

मजबूर न breakकरना कई चीजों को अनुमति देता है जो अन्यथा करना मुश्किल हो सकता है। दूसरों ने समूहन मामलों को नोट किया है, जिसके लिए कई गैर-तुच्छ मामले हैं।

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

breakउपयुक्त टिप्पणी के साथ प्रतिस्थापित करने के लिए यह अच्छा अभ्यास है , अगर मामले में कोई कोड है। अन्यथा, कोई लापता को ठीक करेगा break, और एक बग का परिचय देगा।

Comments

डफ डिवाइस उदाहरण (+1) के लिए धन्यवाद । मुझे इस बारे में पता नहीं था।

— ट्रेडरज

Answer 7

सी में, जहां मूल प्रतीत होता है, switchकथन का कोड ब्लॉक कोई विशेष निर्माण नहीं है। यह एक ifबयान के तहत ब्लॉक के रूप में, कोड का एक सामान्य ब्लॉक है ।

switch ()
{
}

if ()
{
}

caseऔर defaultइस ब्लॉक के अंदर जंप लेबल हैं, विशेष रूप से संबंधित switch। वे के रूप में सामान्य कूद लेबल के रूप में नियंत्रित किया जाता है goto। एक विशिष्ट नियम है जो यहां महत्वपूर्ण है: कोड प्रवाह को बाधित किए बिना, कोड में जंप लेबल लगभग हर जगह हो सकते हैं।

एक सामान्य कोड ब्लॉक के रूप में, इसे एक कंपाउंड स्टेटमेंट होने की आवश्यकता नहीं है। लेबल वैकल्पिक हैं, भी। ये switchC में मान्य कथन हैं :

switch (a)
    case 1: Foo();

switch (a)
    Foo();

switch (a)
{
    Foo();
}

C मानक स्वयं इसे एक उदाहरण के रूप में देता है (6.8.4.2):

switch (expr) 
{ 
    int i = 4; 
    f(i); 
  case 0: 
    i=17; 
    /*falls through into default code */ 
  default: 
    printf("%d\n", i); 
} 

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

इसके अलावा, defaultएक जंप लेबल भी है, और इस तरह अंतिम केस होने की आवश्यकता के बिना, कहीं भी हो सकता है।

यह डफ का उपकरण भी बताता है:

switch (count % 8) {
    case 0: do {  *to = *from++;
    case 7:       *to = *from++;
    case 6:       *to = *from++;
    case 5:       *to = *from++;
    case 4:       *to = *from++;
    case 3:       *to = *from++;
    case 2:       *to = *from++;
    case 1:       *to = *from++;
            } while(--n > 0);
}

क्यों गिर-के माध्यम से? क्योंकि कोड के एक सामान्य ब्लॉक में सामान्य कोड फ्लो में, अगले स्टेटमेंट के लिए फ़ॉल-थ्रू की उम्मीद की जाती है , जैसे आप एक ifकोड ब्लॉक में इसकी अपेक्षा करेंगे ।

if (a == b)
{
    Foo();
    /* "Fall-through" to Bar expected here. */
    Bar();
}

switch (a)
{
    case 1: 
        Foo();
        /* Automatic break would violate expected code execution semantics. */
    case 2:
        Bar();
}

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

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

int a = 10;

switch (a)
{
    switch (a)
    {
        case 10: printf("Done.\n");
    }
}

सी मानक इसकी परवाह करता है (6.8.4.2.4):

एक मामला या डिफ़ॉल्ट लेबल केवल निकटतम एन्क्लोजिंग स्विच स्टेटमेंट के भीतर पहुंच योग्य है।

Answer 8

कई लोगों ने पहले से ही कई स्थितियों के मिलान की धारणा का उल्लेख किया है, जो समय-समय पर बहुत मूल्यवान है। हालाँकि, कई स्थितियों से मेल खाने की क्षमता के लिए जरूरी नहीं है कि आप प्रत्येक शर्त के साथ ठीक वैसा ही करें जो मेल खाता हो। निम्नलिखित को धयान मे रखते हुए:

switch (someCase)
{
    case 1:
    case 2:
        doSomething1And2();
        break;

    case 3:
        doSomething3();

    case 4:
        doSomething3And4();
        break;

    default:
        throw new Error("Invalid Case");
}

कई स्थितियों के दो अलग-अलग तरीके सेट हैं जिनका मिलान यहां किया जा रहा है। शर्तों 1 और 2 के साथ, वे कोड के ठीक उसी प्लॉट से गुजरते हैं और ठीक उसी काम को करते हैं। शर्तों 3 और 4 के साथ, हालांकि, वे दोनों कॉल करके समाप्त होते हैं doSomething3And4(), केवल 3 कॉल doSomething3()।

Comments

पार्टी के लिए देर से, लेकिन यह बिल्कुल नहीं है "1 और 2" जैसा कि फ़ंक्शन नाम से पता चलता है: तीन अलग-अलग राज्य हैं जो सभी को case 2ट्रिगर करने में कोड की ओर ले जा सकते हैं , इसलिए यदि हम सही होना चाहते हैं (और हम) असली फ़ंक्शन का नाम doSomethingBecause_1_OR_2_OR_1AND2()या कुछ और होना चाहिए (हालांकि वैध कोड जिसमें एक अपरिवर्तनीय दो अलग-अलग मामलों से मेल खाता है, जबकि अभी भी अच्छी तरह से लिखित कोड लगभग न doSomethingBecause1or2()

— के बराबर है

दूसरे शब्दों में, doSomething[ThatShouldBeDoneInTheCaseOf]1And[InTheCaseOf]2()। यह तार्किक और / या का जिक्र नहीं है।

— पैंजरक्रिस

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

— माइक 'पोमैक्स' कमरमन्स

Answer 9

आपके दो सवालों के जवाब देने के लिए।

C को ब्रेक की आवश्यकता क्यों है?

यह एक "पोर्टेबल असेंबलर" के रूप में Cs जड़ों तक आता है। जहां इस तरह का psudo कोड आम था: -

    targets=(addr1,addr2,addr3);
    opt = 1  ## or 0 or 2
switch:
    br targets[opt]  ## go to addr2 
addr1:
    do 1stuff
    br switchend
addr2:
    do 2stuff
    br switchend
addr3
    do 3stuff
switchend:
    ......

स्विच स्टेटमेंट को उच्च स्तर पर समान कार्यक्षमता प्रदान करने के लिए डिज़ाइन किया गया था।

क्या हमारे पास कभी भी बिना ब्रेक के स्विच होते हैं?

हां यह काफी सामान्य है और कुछ उपयोग के मामले हैं;

सबसे पहले आप कई मामलों के लिए एक ही कार्रवाई करना चाह सकते हैं। हम एक दूसरे के ऊपर मामलों को स्टैक करके ऐसा करते हैं:

case 6:
case 9:
    // six or nine code

राज्य मशीनों में एक और उपयोग का मामला यह है कि एक राज्य को संसाधित करने के बाद हम तुरंत दूसरे राज्य में प्रवेश और प्रक्रिया करना चाहते हैं:

case 9:
    crashed()
    newstate=10;
case 10:
    claim_damage();
    break;

Answer 10

ब्रेक स्टेटमेंट एक जम्पिंग स्टेटमेंट है जो उपयोगकर्ता को पास के एन्क्लोजिंग स्विच (आपके मामले के लिए) से बाहर निकलने की अनुमति देता है, जबकि, फॉर या फॉरचेट। यह उतना ही आसान है।

Answer 11

मुझे लगता है कि ऊपर लिखे सभी के साथ - इस धागे का मुख्य परिणाम यह है कि यदि आप एक नई भाषा डिज़ाइन करना चाहते हैं - डिफ़ॉल्ट होना चाहिए कि आपको एक breakबयान जोड़ने की आवश्यकता नहीं है और कंपाइलर इसे मानेंगे जैसे आपने किया था।

यदि आप उस दुर्लभ मामले को चाहते हैं, जहां आप अगले मामले को जारी रखना चाहते हैं - बस इसे एक continueबयान के साथ बताएं।

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

Comments

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

— DeveloperDon

C के पास कई उद्देश्यों के लिए समान कीवर्ड का उपयोग करने की लंबी परंपरा है। के बारे में सोचो *, &, staticआदि

— idrougge