सane C++ Libraries

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

एक नया project, “Sane C++ Libraries,” C++ के लिए एक हल्का, STL-रहित alternative ecosystem प्रदान करना चाहता है, जिसमें तेज़ compile times, सरल abstractions, और async I/O, JSON, तथा reflection जैसी व्यावहारिक utilities हों। टिप्पणीकार बँटे हुए हैं: कुछ लोग minimalism, explicit error handling, और exceptions, RTTI, तथा smart pointers से बचने पर जोर का स्वागत करते हैं, जबकि अन्य मानते हैं कि standard library से दूरी fragmentation बढ़ाती है और mature, well-optimized components की कुर्बानी देती है। यह चर्चा C++ में performance, simplicity, portability, और standard library बनाम custom या third-party foundations पर निर्भरता के बीच लंबे समय से चले आ रहे तनावों को उजागर करती है.

समग्र लक्ष्य और स्थिति

  • लाइब्रेरी का उद्देश्य एक “वैकल्पिक C++ दुनिया” को मॉडल करना है, जो Python/Node/Zig/C जैसी हो: व्यावहारिक कार्यक्षमता, async I/O, platform abstraction, छोटे binaries, बिना exceptions/RTTI/stdlib.
  • लेखक मज़ा, सरलता, और हर edge case के बजाय “95% use cases” पर ध्यान देने पर ज़ोर देता है।
  • कुछ लोग इसे unsafe C और bloated libstdc++ के बीच एक मध्य मार्ग मानते हैं; जबकि अन्य “no stdlib / no exceptions / custom atomics” को स्वभावतः “sane” नहीं मानते।

Stdlib से बचाव और ecosystem fragmentation

  • कई टिप्पणीकारों का आपत्ति है कि STL को नज़रअंदाज़ करना fragmentation और खराब interop को और बढ़ाएगा; उन्हें पहले ही हर C++ library द्वारा अपनी अलग String/Vector types बनाने से परेशानी होती है।
  • अन्य लोग तर्क देते हैं कि STL में design/compatibility baggage है (जैसे vector<bool>, standard maps, std::regex, भारी templates, धीमे debug builds) और कई गंभीर projects पहले से अपनी core library खुद बनाते हैं।
  • Abseil से तुलना: Abseil STL का पूरक है, जबकि यह project जानबूझकर उसका अधिकांश भाग replace करता है।

Containers, algorithms, और data structures

  • मौजूदा container set को अधूरा माना जा रहा है; standard-like sets, queues, deques, और hash maps की कमी कुछ लोगों के लिए blocker है।
  • कुछ users stack/deque पर बहुत निर्भर हैं; लेखक deque को लेकर skeptical है और vector-based solutions तथा arena-style containers को प्राथमिकता देता है।
  • “Algorithms” library में अभी bubbleSort पहले दिखता है; इससे आलोचना हुई, जिस पर लेखक ने स्पष्ट किया कि यह placeholder है और समय के साथ विस्तार होगा।

Memory management, smart pointers, और exceptions

  • project जानबूझकर SharedPtr/UniquePtr को शामिल नहीं करता, इस सिद्धांत पर कि बहुत सारे छोटे heap objects और अस्पष्ट/साझा ownership से बचना चाहिए।
  • कुछ लोग इससे सख़्त असहमत हैं, वे सभी heap objects के लिए smart pointers चाहते हैं और उन्हें zero- या low-overhead safety tools मानते हैं।
  • अन्य लोग vectors/arenas, handles, और स्पष्ट ownership groups वाले patterns का वर्णन करते हैं, smart pointers के बजाय।
  • बड़ा debate: कई टिप्पणीकार exception-free C++ (अक्सर ErrorOr-style types के साथ) को सामान्य और व्यावहारिक मानते हैं; अन्य insist करते हैं कि C++ किसी भी meaningful sense में exception-free नहीं हो सकता, और कहते हैं कि सभी error handling “exceptions in disguise” है।
  • C++ exceptions को लेकर चिंताओं में non-zero overhead, RTTI, hidden control flow, function signatures से throwing behavior स्पष्ट न होना, और केवल “happy path” code को प्रोत्साहित करना शामिल है।

Atomics और low-level चिंताएँ

  • Custom atomics पर सवाल उठाए जाते हैं, क्योंकि std::atomic C++ memory model से गहराई से जुड़ा है।
  • no-stdlib नियम तत्काल कारण है; लेखक भविष्य में एक opt-in flag का संकेत देता है जिससे जहाँ उपलब्ध हो वहाँ standard headers इस्तेमाल किए जा सकें।

Build system और macros

  • C++ में builds को describe करना “sane” नहीं माना जाता; declarative approach के पक्ष में तर्क scalability और simplicity पर आधारित हैं।
  • लेखक जवाब देता है कि लोकप्रिय “declarative” tools (जैसे CMake) वास्तव में imperative DSLs ही हैं।
  • कुछ लोगों को project का macro usage भी un-“sane” लगता है; लेखक बताता है कि अधिकतर macros platform switches हैं, और reflection में optional macros भी हैं।