C प्रोग्रामिंग भाषा (C भाषा की समस्याएँ)

 (hut.mearie.org)
15 पॉइंट द्वारा dalinaum 2021-04-05 | 7 टिप्पणियां | WhatsApp पर शेयर करें

  • मेमोरी समस्याएँ: GC, static analysis आदि जैसे किसी भी टूल की मदद नहीं मिलती.

  • undefined behavior: इसका उपयोग मुख्यतः low-level environments में होता है और optimization की मांग अधिक रही, तथा optimization के लिए undefined behavior बढ़ता गया. low-level performance और portability, दोनों को एक साथ हासिल नहीं कर पाया.

  • बड़े पैमाने के प्रोग्रामिंग के लिए अनुपयुक्त: modules और package manager का अभाव. #pragma once जैसी व्यापक रूप से इस्तेमाल होने वाली चीज़ों का भी कोई standard नहीं है.

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

7 टिप्पणियां

 
ffdd270 2021-04-05

अच्छा लेख साझा करने के लिए धन्यवाद। हालांकि, एक छोटी-सी बात थोड़ी अजीब लगी, इसलिए यह टिप्पणी छोड़ रहा हूँ।

  • शायद जब आपने इसे पहली बार 2011 में लिखा था, तब यह नहीं थे, लेकिन अब C package manager के कुछ विकल्प आ चुके हैं। Conan भी है, और MS का vcpkg भी है। npm की तुलना में इनमें अभी कुछ कमियाँ हैं (vcpkg में version management पर अभी beta का टैग लगा है, और conan के पास vcpkg की तुलना में सामग्री कम है), लेकिन जिस दौर में कुछ भी नहीं था, उससे अब स्थिति काफी बेहतर हो गई है।
 
lifthrasiir 2021-04-09

यह लेख लिखने वाला मैं ही हूँ (हाहा...). फिलहाल साइट soft release स्थिति में है और मैं प्रयोग के तौर पर लेख लिख रहा हूँ, इसलिए कृपया समझें कि सामग्री लगातार संशोधित हो सकती है. मैं खुद भी tracking कर रहा हूँ, लेकिन आप ईमेल से अपनी राय भेजें तो वह भी स्वीकार है, इसलिए संदर्भ के लिए बता रहा हूँ.

जैसा आपने कहा, vcpkg इस समय सबसे promising package manager लगता है, और Conan भी वास्तव में काफ़ी पहले से मौजूद project है (मूल लेखन समय से बहुत दूर नहीं). लेकिन इन projects की सबसे बड़ी विशेषता यह है कि इनके पास खुद का build system नहीं है, बल्कि ये meta build system हैं. (यह सोचें कि मुख्य support target CMake खुद एक meta build system है, तो शायद इसे meta-meta build system भी कहा जा सकता है...) इसलिए build system से खुद पैदा होने वाली समस्याओं को ये खास तौर पर हल नहीं कर पाते. vcpkg में इस पर थोड़ा ज़्यादा विचार किया गया लगता है; उदाहरण के लिए, अगर एक ही dependency के अलग-अलग version किसी project में (अलग dependency path के जरिए) चाहिए हों, तो enlistment को बाँटना संभव है, लेकिन यह build system की मूल सीमाओं को बस bypass करने का तरीका भर है. इसके उलट, Rust और Cargo में इस स्थिति में दोनों version build करके एक crate से reference करने में कोई दिक्कत नहीं होती.

इसके अलावा, लगता है कि vcpkg का Visual Studio में अभी NuGet स्तर का tool integration भी नहीं है (सिर्फ MSBuild integration...), और Linux/BSD distribution के package manager के साथ integration भी बहुत खास नहीं दिखता. यह समस्या फिलहाल language-specific package manager के सामने मौजूद सबसे बड़ी समस्याओं में से एक है; Rust जैसी नई भाषाएँ इसे अलग-अलग मोर्चों पर हल कर रही हैं, लेकिन C/C++ package manager को तो हर हाल में मौजूदा systems के साथ integration की दिशा में बढ़ना चाहिए, और वही काम अभी तक काफ़ी धीमा है. इस हिस्से का समाधान होने के बाद ही आखिरकार यह कहा जा सकेगा कि vcpkg जैसे tools C/C++ development में सामान्य रूप से उपयोग किए जा सकने वाले tools बन गए हैं. यही वह मुख्य कारण है जिसकी वजह से मैंने लेख में package system को कम आंका है. (लेख में बताई गई single-file library की बाढ़ भी अप्रत्यक्ष रूप से इस बात का प्रमाण है कि vcpkg जैसी systems अभी उतनी प्रभावी अपील नहीं कर पा रही हैं.)
 
ffdd270 2021-04-12

विस्तृत जवाब के लिए धन्यवाद। आखिरकार इसकी बुनियाद = m=.. build पर है, इसलिए npm या अन्य package manager की तरह इसे फॉलो न कर पाने की एक दीवार तो होगी ही। लगता है vcpkg इन दिनों version को लेकर काफी chintan में है, लेकिन इसे पार करना आसान नहीं होगा।

शायद C++20 का module system इस समस्या का समाधान बन सकता है... लेकिन तब दायरा C भाषा से आगे निकल जाएगा(...). लगता है C भाषा के लिए अब सिर्फ कांटों भरा रास्ता ही बचा है। अगर अब C20 को मानकीकृत भी किया जाए, तब भी C++ की तरह version transition rate इतना ऊँचा नहीं होगा..
 
functor 2021-04-06

अच्छी राय के लिए धन्यवाद।

मेरी व्यक्तिगत राय यह है। C package manager के कुछ विकल्प होना अच्छी बात है, लेकिन समस्या यह लगती है कि ऐसे package manager का ज़्यादा इस्तेमाल नहीं होता। थोड़ा और सटीक रूप से कहें तो, C की legacy पहले से ही इतनी विशाल है कि ऊपर बताए गए समस्याओं को हल करने के लिए शायद हम बहुत आगे निकल आए हैं। इसलिए शायद Rust जैसी नई languages पर जाने की कोशिशें और ज़्यादा हो रही हैं।
 
ffdd270 2021-04-06

आपकी बात सुनकर दोबारा सोचने पर लगा कि ऊपर बताए गए package managers का फोकस C language की उम्र बढ़ाने से ज़्यादा, C language का इस्तेमाल करना ही पड़ने वाले programmers की उम्र बढ़ाने पर है।

अब जब नए घर (C++, Rust...) में शिफ्ट होने का समय आ गया है, तब पुराने घर के OpenGL या Lua जैसे furniture की ज़रूरत पड़ती है। पहले package manager न हो तो उन्हें हाथ से उठाकर ले जाना पड़ता था (linking करना, make चलाना, DLL या lib version न मिलने से बाल नोचना... LNK error देखते-देखते कूद जाने का मन होना...) लेकिन अब package manager है, तो packing-and-moving service की तरह उन्हें साफ-सुथरे ढंग से ले जाया जा सकता है। इतना कुछ पहले से बना हुआ है, इसलिए नए घर में भी कभी-कभी उनका इस्तेमाल करना ही पड़ेगा...

अब language खुद की खूबियों से ज़्यादा, अब तक जमा हुए अनुभव और legacy का फायदा बड़ा लगने लगे तो सच में महसूस होता है कि यह मरती हुई language है(...
 
galadbran 2021-04-08

कई मायनों में लगता है कि Rust के पास next C/C++ की छवि सबसे मज़बूती से है। (और next मानी जाने वाली कुछ भाषाओं में यह अपेक्षाकृत सबसे जटिल लगने वाली भाषा की छवि भी रखती है... हाहा)
 
dalinaum 2021-04-10

ऐसा लगता है कि सिर्फ़ इमेजिंग ही नहीं, Rust वास्तव में भी कठिन है.