C++ को C++ ही रहना चाहिए

आधुनिक C++ की प्रतिक्रिया

• तेज़ विभाजन: कुछ लोगों को C++20/23 गुणवत्ता-ए-जीवन में बहुत बड़ा उछाल लगता है (जैसे optional, expected, filesystem, structured bindings, if/switch init, lambdas) और वे “modern C++” का आनंद लेते हैं।
• दूसरे, खासकर लंबे समय से उपयोग करने वाले, नए मानकों को अलंकृत और अप्रिय मानते हैं, और “C with classes” या बहुत छोटे उपसमुच्चय को पसंद करते हैं।
• कई डेवलपर व्यवहार में खुद को परियोजना-विशिष्ट उपसमुच्चय तक सीमित रखते हैं, लेकिन बड़े कोडबेस में और तब यह कठिन हो जाता है जब नई सुविधाएँ (जैसे move semantics) बोइलरप्लेट या सूक्ष्म आवश्यकताएँ लाती हैं।

टूलिंग, मॉड्यूल, और निर्भरता प्रबंधन

• इसे व्यापक रूप से एक बड़ी कमजोरी माना जाता है: कोई मानक पैकेज मैनेजर नहीं, और dependencies, testing, logging, आदि के लिए कोई एकीकृत कहानी नहीं।
• modules को आशाजनक माना जाता है, लेकिन असमान compiler और tooling support के कारण व्यावहारिक रूप से अनुपयोगी।
• vcpkg की आलोचना इसकी fragile behavior, बदले हुए sources, और commits पर pinned versioning के लिए की जाती है; Bazel/Buck और Nix/Guix को आंशिक उत्तर के रूप में उल्लेख किया जाता है।
• कुछ टीमें toolchains को version control में check in करने या VMs का snapshot लेने का सहारा लेती हैं।

कम्पाइलेशन मॉडल और प्रदर्शन

• compile times को शीर्ष दर्द-बिंदु माना जाता है, और अक्सर नई सुरक्षा सुविधाओं से भी अधिक प्राथमिकता दी जाती है।
• कारणों पर चर्चा होती है: headers का बार-बार parsing, हर translation unit पर template instantiation, duplicates हटाने के लिए अतिरिक्त linker work, और कठिन grammar; इस बात पर असहमति कि कौन-सा कारक हावी है।
• Go, Rust, Zig, और C से तुलना यह उजागर करती है कि C/C++ का preprocessing और compilation model कैसे पुराना पड़ता जा रहा है, यहाँ तक कि precompiled headers या modules के साथ भी।

मेमोरी सुरक्षा, नियम, और भाषा की दिशा

• इस पर असहमति है कि C++ उपयोगकर्ता वास्तव में memory safety की कितनी मांग करते हैं; कुछ कहते हैं कि जिनके लिए यह महत्वपूर्ण था वे छोड़ चुके हैं, जबकि अन्य तर्क देते हैं कि बहुत से लोग इसे चाहते हैं लेकिन अतिरिक्त paid tools के माध्यम से नहीं।
• “Half-measure” safety (opt-in, आंशिक कवरेज, runtime-costly) को सीमित लाभ का माना जाता है।
• थ्रेड सरकारी दबाव (NSA/CISA guidance, लंबित US/EU नियम) पर चर्चा करता है जो memory-safe languages की ओर धकेलता है; सीधे प्रतिबंध नहीं, लेकिन procurement और paperwork दबाव की उम्मीद है।
• कुछ लोग इस paper को Rust के प्रति रक्षात्मक प्रतिक्रिया के रूप में देखते हैं, जिसे कई लोग systems work के लिए C++ replacement के रूप में विश्वसनीय मानते हैं।

स्टैंडर्ड लाइब्रेरी, एर्गोनॉमिक्स, और “zero-cost”

• शिकायतें कि std में high-performance primitives नहीं हैं (specialized allocators, lock-free/wait-free structures, IPC, high-performance threading) और यह games/DBs/OS-level workloads के लिए tuned नहीं है।
• दूसरे तर्क देते हैं कि ये external libraries में होने चाहिए और कोई एक generic high-performance design सभी workloads के लिए उपयुक्त नहीं होता।
• “zero-cost abstraction” आदर्श पर प्रश्न उठाए जाते हैं; hidden control flow (constructors, destructors, copies) और exceptions का वास्तविक cost हो सकता है यदि उनका गलत उपयोग हो या optimization कमजोर हो।
• std::print जैसे नए APIs को पुराने idioms (streams) की तुलना में customization के लिए अधिक cumbersome माना जाता है, जो poor ergonomics की धारणा को मजबूत करता है।

सामान्यता, विरासत, और विकल्प

• इस पर विस्तृत बहस कि क्या “used by millions” यह साबित करता है कि C++ एक अच्छा general-purpose language है; कुछ इसे fallacy कहते हैं, दूसरे कहते हैं कि विभिन्न domains में वास्तविक-विश्व व्यापक उपयोग व्यावहारिक रूप से उपयुक्तता का प्रमाण है।
• legacy और inertia का बार-बार उल्लेख होता है: कई लोग C++ केवल इसलिए लिखते हैं क्योंकि पहले का code ऐसा था; विशाल मौजूदा codebases breaking changes या wholesale rewrites को अव्यावहारिक बनाते हैं।
• कुछ का तर्क है कि C++ को सबसे तेज़ systems language होने पर दोगुना जोर देना चाहिए; अन्य मानते हैं कि इसका इतिहास और जटिलता इसे Rust या Go की तुलना में नए programmers के लिए खराब विकल्प बनाते हैं।
• Carbon, cppfront, और “C with templates” जैसी प्रस्तावनाओं को नई शुरुआत के प्रयास के रूप में उल्लेख किया गया है, लेकिन adoption और committee की radical, breaking changes करने की क्षमता पर संदेह बना हुआ है।