ऑर्थोडॉक्स C++ (2016)

मूल लेख ↗ Hacker News चर्चा ↗

एक लंबे समय से चल रही ब्लॉग पोस्ट “ऑर्थोडॉक्स C++” — C++ के एक न्यूनतम, C-जैसे subset — की वकालत करती है, जो exceptions, RTTI, STL के अधिकांश हिस्सों और नए “Modern C++” फीचर्स से बचती है; इससे भाषा के उपयोग के तरीके पर फिर बहस छिड़ जाती है। कुछ डेवलपर, खासकर गेम और embedded क्षेत्रों से, इस सीमित शैली का बचाव complexity, performance और determinism पर नियंत्रण रखने के व्यावहारिक तरीके के रूप में करते हैं; जबकि अन्य तर्क देते हैं कि यह RAII, type inference, और metaprogramming जैसी उपयोगी abstractions को अनावश्यक रूप से अस्वीकार करता है, जो बड़े सिस्टम को संभालने योग्य बनाती हैं। यह चर्चा आगे भाषा के विकास, standard library design, और इस प्रश्न तक फैलती है कि क्या Rust, Zig, Nim, या C++ के “better C” subsets safety, expressiveness, और maintainability के बीच अधिक स्वस्थ संतुलन दे सकते हैं।

“ऑर्थोडॉक्स C++” पर समग्र प्रतिक्रिया

  • कई लोगों को लेख सतही या सिद्धांतवादी लगता है: यह सूक्ष्म मार्गदर्शन या तर्क देने के बजाय निषेधों की सूची देता है।
  • अन्य, खासकर गेम/एम्बेडेड पृष्ठभूमि वाले, कहते हैं कि यह लंबे समय से चली आ रही व्यावहारिक प्रथा को ही काफी हद तक दर्शाता है: छोटा subset, RTTI/exception नहीं, सीमित stdlib।
  • कई लोग नोट करते हैं कि C++ स्वभाव से multi-paradigm है और हर गंभीर टीम पहले से ही अपना subset चुनती है; “orthodox” बस एक और flavor है।

C बनाम C++ और भाषा की जटिलता

  • कुछ C प्रोग्रामर तर्क देते हैं कि C++ मानसिक बोझ बहुत बढ़ा देता है: C की तुलना में अधिक hidden behavior, lifetime rules, और “footguns”।
  • अन्य जवाब देते हैं कि C में भी hidden complexity और UB की कमी नहीं है; C++ कम से कम stronger typing और बेहतर abstractions देता है।
  • एक बार-बार आने वाला विषय: इंजीनियर domain problems हल करने में व्यस्त रहते हैं और हर नए C++ feature या version को ट्रैक नहीं करना चाहते।

Modern features: auto, range-for, RTTI, exceptions

  • auto के साथ range-based for को व्यापक रूप से readable और iterator boilerplate की तुलना में कम error-prone माना जाता है।
  • आलोचक कहते हैं कि auto code reviews और diffs में types को अस्पष्ट कर देता है; समर्थक जवाब देते हैं कि type inference कई भाषाओं में standard है और IDEs इसे हल कर देते हैं।
  • RTTI और dynamic_cast पर रोक को कुछ लोग अनावश्यक मानते हैं; अन्य इसे code smell कहते हैं और performance/control के लिए manual या custom RTTI को पसंद करते हैं।
  • Exceptions बेहद विवादास्पद हैं:
    • anti-exception पक्ष unpredictability, debugging में कठिनाई, determinism की चिंताएँ, और “यह function क्या throw कर सकता है?” जैसे अस्पष्ट contract का हवाला देता है।
    • pro-exception पक्ष जोर देता है कि इन्हें केवल वास्तव में exceptional contract violations के लिए इस्तेमाल किया जाए, routine error handling के लिए नहीं।

Standard library, containers, और I/O

  • std::map, std::unordered_map, std::deque, और यहाँ तक कि std::vector की performance, cache behavior, concurrency, और awkward APIs के लिए कड़ी आलोचना की जाती है।
  • अन्य तर्क देते हैं कि वे वास्तविक दुनिया के विशाल कोड के लिए पूरी तरह पर्याप्त हैं; समस्याएँ मुख्यतः extreme high-throughput/low-latency contexts में आती हैं।
  • iostreams को व्यापक रूप से नापसंद किया जाता है; कई लोग C-style printf या नए fmt/<format> APIs को पसंद करते हैं। कुछ कहते हैं कि iostream से बचते हुए भी type-safe formatting का उपयोग करना ही समझदारी वाला मध्य मार्ग है।

Template metaprogramming और विकल्प

  • कुछ लोग भारी template metaprogramming और functional styles का उत्सव मनाते हैं, खासकर नए constexpr/consteval/concepts के साथ, क्योंकि ये अनोखी शक्ति देते हैं।
  • अन्य compilation times और unreadable errors की शिकायत करते हैं, और संयमित उपयोग की वकालत करते हैं।
  • Rust, Zig, Nim, D, और “better C” approaches जैसे विकल्प बार-बार सामने आते हैं; जहाँ चुनाव उपलब्ध हो, कई लोग कहते हैं कि वे C++ से पूरी तरह बचना चाहेंगे।