वे स्पष्ट बातें जो C भाषा को करनी चाहिए

 (digitalmars.com)
2 पॉइंट द्वारा GN⁺ 2025-01-13 | 1 टिप्पणियां | WhatsApp पर शेयर करें

  • C के स्पष्ट सुधार बिंदु

    • C23 मानक: C भाषा में नियमित रूप से सुधार होते रहे हैं और यह अब C23 तक पहुँच चुकी है। फिर भी कुछ समस्याएँ अब भी अनसुलझी हैं।
    • Dlang कम्युनिटी का प्रयास: D प्रोग्रामिंग भाषा के compiler में C compiler (ImportC) को एम्बेड करके इन समस्याओं को हल करने का एक अवसर दिया गया है।

  • स्थिर expression का मूल्यांकन

    • समस्या: C compile time पर सरल expressions की गणना कर सकती है, लेकिन functions को execute नहीं कर सकती।
    • ImportC का समाधान: ImportC compile time पर functions के execution की अनुमति देता है, जिससे यह सीमा दूर होती है।

  • compile time unit test

    • C में समस्या: C कोड में unit test के लिए अलग build target चाहिए होता है, जिससे प्रक्रिया झंझटभरी हो जाती है।
    • ImportC का लाभ: ImportC function evaluation के जरिए compile time पर unit test आसानी से चलाने योग्य बनाता है।

  • declarations का forward reference

    • C की सीमा: C declarations के क्रम के प्रति संवेदनशील है और forward reference की अनुमति नहीं देती।
    • ImportC का लाभ: ImportC declarations के क्रम से बंधा नहीं है और किसी भी क्रम में global declarations की अनुमति देता है।

  • declarations import करना

    • मौजूदा तरीके की समस्या: हर external module के लिए .h file लिखनी पड़ती है, जो झंझटभरा है।
    • ImportC का समाधान: ImportC .h file के बिना भी declarations import कर सकता है, इसलिए यह अधिक efficient है।

  • संदर्भ सामग्री

    • ImportC दस्तावेज़: ImportC के बारे में विस्तृत जानकारी प्रदान करते हैं।
    • D भाषा दस्तावेज़: D भाषा के बारे में अतिरिक्त जानकारी प्रदान करते हैं।

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-01-13
Hacker News राय

  • C भाषा में header files का public और private, interface और implementation को साफ़ तौर पर अलग कर पाना अच्छा है। .h files के ज़रिए library का उपयोग कैसे करना है, यह आसानी से समझा जा सकता है

    • .h files में documentation केंद्रित होने से वे .c files से अलग दिखती हैं
    • documentation को .c files में भी रखा जा सकता है, लेकिन इससे interface पढ़ना असुविधाजनक हो जाता है

  • कुछ लोगों का मानना है कि C भाषा में compile time पर functions चलाना संभव होना चाहिए, लेकिन जिन functions का execution time लंबा हो, वे समस्या बन सकते हैं

    • उदाहरण के तौर पर busybeaver function है

  • constant expression evaluation, compile-time unit tests, declarations के forward reference, और declarations import करने जैसे मुद्दों के समाधान को लेकर जिज्ञासा है

    • constant expression evaluation: translation unit के भीतर काम किया जाए तो यह सरल है, लेकिन code duplication की ज़रूरत पड़ती है
    • compile-time unit tests: macro से व्यक्त किया जाए तो संभव है, लेकिन पहला point जोड़ दिया जाए तो यह आसान हो जाता है
    • declarations के forward reference: compiler को दो passes की ज़रूरत पड़ सकती है, जिससे performance पर असर पड़ सकता है
    • declarations import करना: इससे C में templates लागू करने के तरीके टूट सकते हैं

  • C code के लिए unit tests लिखना एक अच्छे build system और थोड़े boilerplate के साथ संभव है

    • उदाहरण के तौर पर npy library का test code है

  • जब constant expression evaluation जटिल हो जाती है, तो compiler की speed धीमी पड़ सकती है और VM की ज़रूरत हो सकती है

    • यह राय भी है कि C++20 की परिभाषा की तुलना में modules को symbols के रूप में import करने की दिशा बेहतर होती

  • compile-time unit tests developer के control को कम कर देते हैं और काम पूरा करने के लिए अनावश्यक प्रक्रियाएँ मांगते हैं

    • build failure tests अंतिम build के लिए अच्छे हैं, लेकिन बीच के builds के लिए उपयुक्त नहीं हैं

  • इस पर चर्चा कि function definitions को "top-down" तरीके से करना बेहतर है या नहीं

    • Python जैसी भाषाओं में भी top-down definition आम है
    • यह सवाल भी है कि क्या top-down definition कुछ खास तरह के code के लिए ज़्यादा उपयुक्त है

  • C भाषा में जो features जोड़े जाने चाहिए

    • pointer और length को encode करने वाले slice type का समर्थन
    • reentrant और thread-safe API
    • Go और Zig के defer जैसे feature का standardization
    • Unicode और UTF-8 के लिए portable support

  • C का simple implementation उसकी ताकत है, और उसके दायरे को बहुत बड़ा बढ़ाना अच्छा विचार नहीं है

    • Scheme की तरह "small" version और "large" version की specification हो सकती है

  • function definitions को ऊपर से नीचे लिखना बेहतर होने के कारण

    • यह function के भीतर code लिखने के तरीके जैसा है
    • module के भीतर functions की location साफ़ रहती है
    • circular dependencies को स्पष्ट रूप से पहचाना जा सकता है
    • circular dependencies codebase को जटिल बनाती हैं और module को समझना कठिन करती हैं
    • OCaml functions के बीच circular dependencies की अनुमति नहीं देता