C++ सुरक्षा, संदर्भ में

समिति, प्रक्रिया, और सुरक्षा विशेषताएँ

• कई टिप्पणीकार इस बात से निराश हैं कि अच्छे सुरक्षा विचार मौजूद हैं, लेकिन मानकीकरण धीमा और असंगत है (उदा., std::span C++26 तक .at() के बिना शिप हुआ, operator[] अभी भी unchecked है)।
• यह स्पष्ट किया गया कि C++ समिति मुख्यतः उन प्रस्तावों को अनुमोदित करती है जिनके पीछे काम करने वाली implementations होती हैं; वह एकतरफा नया C++ “थोप” नहीं सकती।
• Backward compatibility और ABI stability को ऐसे प्रमुख प्रतिबंध माना जाता है जो गहरे सुरक्षा परिवर्तन रोकते हैं (उदा., fat pointers, breaking syntax, epochs)।

संस्कृति और डिफ़ॉल्ट असुरक्षा

• कई कहानियाँ बताती हैं कि टीमें sanitizers बंद कर देती हैं, ASAN reports की अनदेखी करती हैं, debuggers से इनकार करती हैं, और out-of-bounds access को तब तक स्वीकार्य मानती हैं जब तक वह “crash” न करे।
• कुछ लोग तर्क देते हैं कि यह मूलतः attitude problem है: tools पहले से मौजूद हैं, लेकिन बहुत से developers और orgs तब तक उनका उपयोग नहीं करेंगे जब तक उन्हें strongly incentivized या punished न किया जाए।
• अन्य लोग जवाब देते हैं कि हर software को hardening के एक ही स्तर की ज़रूरत नहीं होती, लेकिन आलोचक कहते हैं कि कोई भी network‑connected app exploit chain का हिस्सा बन सकता है।

Bounds checking और performance tradeoffs

• default bounds checks पर बार-बार बहस होती है: क्या operator[] को abort करना चाहिए, throw करना चाहिए, या unchecked रहना चाहिए; क्या safety default by default होनी चाहिए और एक explicit unsafe_* escape hatch होना चाहिए।
• कुछ लोग तर्क देते हैं कि overhead व्यावहारिक रूप से छोटा है (system-level measurements का हवाला देते हुए) और इसके लायक है; अन्य लोग HPC/embedded workloads पर ज़ोर देते हैं जहाँ कुछ प्रतिशत regression भी मायने रखता है।
• ऐतिहासिक बहाने (“1990 में too slow”) आज कम वैध माने जाते हैं, लेकिन कुछ लोग फिर भी performance को safety से ऊपर रखते हैं।

CVEs, metrics, और filesystem race का उदाहरण

• C/C++ की Rust से raw CVE counts के आधार पर तुलना करने पर तीव्र असहमति है: severity अलग होती है, और language communities यह तय करने में अलग मानदंड रखते हैं कि किसे CVE मिलना चाहिए।
• उदाहरण: एक filesystem TOCTOU issue को Rust CVE और blogged fix मिला; C++ standard libraries ने समान bugs quietly patch किए लेकिन CVEs file नहीं किए, जबकि C++ spec filesystem races को undefined behavior बताता है।
• कुछ लोगों को चिंता है कि C++ actors root causes ठीक करने के बजाय CVE counts “manage” कर सकते हैं; अन्य कहते हैं कि issue को, CVE के बिना भी, जिम्मेदारी से संभाला गया।

Rust और अन्य भाषाओं से तुलना

• कई लोग Rust को एक गुणात्मक छलांग मानते हैं: memory safety by default, encapsulated unsafe, बेहतर thread-safety guarantees, और ऐसी संस्कृति जो safety को प्राथमिक मानती है।
• प्रतिवाद: Rust में भी CVEs हैं; कई Rust crates unsafe का उपयोग करते हैं (अक्सर FFI के लिए); safe Rust को कुछ data structures के लिए indirection (arenas, Rc/Arc, indices) के बिना कठिनाई होती है।
• कुछ लोग ज़ोर देते हैं कि memory safety केवल एक vulnerability class है; memory‑safe languages में भी logic bugs, injection, secrets handling आदि होते हैं, लेकिन अन्य लोग कहते हैं कि bugs की एक बड़ी class को हटाना भी एक “good problem to have” है।

सरकार, उद्योग का दबाव, और C++ का भविष्य

• हाल की सरकार और बड़े विक्रेता रिपोर्टें जो memory‑unsafe languages से दूर जाने की सलाह देती हैं, उन्हें एक महत्वपूर्ण पृष्ठभूमि माना जा रहा है; कुछ लोग लेख को एक रक्षात्मक प्रतिक्रिया के रूप में पढ़ते हैं।
• इस पर बहस है कि क्या C++ non-breaking changes और tooling के माध्यम से memory‑safe languages के साथ वास्तविक “parity” तक पहुँच सकता है, या इसके लिए radical, breaking shifts (epochs, safe subsets, या “Typescript-for-C++” approaches) चाहिए।
• कई लोगों का मानना है कि legacy C++ दशकों तक बना रहेगा, इसलिए बेहतर tools और safer modes महत्वपूर्ण हैं, भले ही नए projects Rust, Go आदि की ओर स्थानांतरित हों।

संज्ञानात्मक भार और project choices

• कई पोस्ट modern C++ को मानसिक रूप से थकाने वाला बताते हैं: complex syntax, भारी template errors, अनेक overlapping features, और subtle UB।
• कुछ लोग कहते हैं कि वे अभी भी C++ का उपयोग केवल legacy code, ecosystem, या domain norms (HPC, game engines) के कारण करते हैं, और अन्यथा Rust या दूसरी भाषाएँ पसंद करते।
• समग्र भावना: C++ को सीमाओं पर अधिक सुरक्षित बनाया जा सकता है, लेकिन नए greenfield work के लिए, बहुत से टिप्पणीकार यदि संभव हो तो इससे बचेंगे।