C++ वाकई बहुत मज़ेदार है

 (learncodethehardway.com)
1 पॉइंट द्वारा GN⁺ 2024-12-25 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • C++11 के बाद C++ की भाषा और ecosystem में बड़ा बदलाव आया है, और खुद चीज़ें बनाते व प्रयोग करते हुए यह फिर से प्रोग्रामिंग का मज़ा जगा देने वाली भाषा बन गई है
  • एक समय C++ को template metaprogramming की अति और standards/pattern-केंद्रित संस्कृति की वजह से कई डेवलपर्स के लिए थका देने वाली भाषा के रूप में याद किया जाता था
  • auto, nullptr, range-for, lambda, <chrono>, smart pointer, <thread> जैसे बदलावों ने C++ की coding style को काफी बदल दिया
  • आधुनिक C++ में filesystem, package management, GUI/TUI, graphics, math, AI, और OS API access तक के लिए विकल्पों की चौड़ाई है, इसलिए मनचाही चीज़ें खुद बनाना आसान हो गया है
  • compiler errors, build tools, standards compliance, ऐतिहासिक जटिलता, और RAII जैसी कमियाँ अब भी हैं, लेकिन रचनात्मक संभावनाएँ इन असुविधाओं से बड़ी हैं

C++ फिर से मज़ेदार क्यों हो गया

  • एक छोटा roguelike game बनाते समय map generation में Dijkstra algorithm का उपयोग करके कमरों को जोड़ने वाली tunnels लागू की गईं, और इस प्रक्रिया में C++ ने प्रयोग करने में ज़्यादा बाधा नहीं डाली
  • FTXUI user interface को SFML render window पर सीधे draw करने जैसा प्रयोग भी संभव था, और इस दौरान C++ की Unicode handling सीखी गई
  • ये काम आसान नहीं थे, लेकिन वास्तव में संभव थे, और “यह आइडिया सचमुच काम कर गया” वाली अनुभूति ही C++ का मज़ा बनाती है
  • प्रोग्रामिंग शुरू करने का कारण किसी अरबपति के लिए और पैसा कमाना, rendering engine से लड़ना, या open source project के ऊपरी ढाँचे को संतुष्ट करना नहीं था, बल्कि आइडिया को लागू करने की खुशी था

template metaprogramming के दौर की थकान

  • 1990 के दशक के अंत से 2000 के दशक की शुरुआत तक C++ में हर चीज़ पर template metaprogramming लागू करने का माहौल बहुत मजबूत था, और इसी दौर को C++ को गैर-मज़ेदार बनाने वाले मोड़ के रूप में देखा गया
  • template से दो संख्याएँ जोड़ने का तरीका सीधे जोड़ने से तेज़ है जैसी बहसें थीं, लेकिन ऐसे उदाहरण भी सामने आए जहाँ वास्तविक assembly output एक जैसा था
  • यह धारणा भी नकारात्मक अनुभव बढ़ाती रही कि C++ standards committee प्रोग्रामर को अच्छी usability देने में उत्साही नहीं थी
  • उस समय C++ को <> angle brackets और जटिल syntax से भरी, लेकिन बदले में कम देने वाली भाषा के रूप में याद किया जाता था
  • Java भी शुरुआत में garbage collector और developer-friendliness की वजह से आकर्षक लगा, लेकिन बाद में boilerplate और design patterns की अति ने वैसी ही थकान पैदा की

C++11 ने भाषा का अनुभव कैसे बदला

  • C++11 में जोड़ी गई सुविधाएँ C++ की छवि को गहराई से बदल देने वाले बदलावों के रूप में देखी जाती हैं
  • मुख्य सुविधाएँ इस प्रकार हैं
    • auto: एक ही type name बार-बार लिखने का बोझ घटाने वाला automatic type inference keyword
    • nullptr: C के NULL की समस्याओं को बेहतर करने वाला null pointer representation
    • range-for: auto के साथ containers पर iterate करना आसान बनाने वाला loop
    • lambda expressions: API design और usability को बहुत बदल सकने वाली lambdas
    • <chrono>: 100ms जैसी अभिव्यक्तियाँ संभव करने वाली type-safe time library
    • <regex>: standard library में शामिल regular expression सुविधा
    • unique_ptr, shared_ptr: ownership और reference counting को संभालने वाले smart pointers
    • <thread>: multithreading को मूल language ecosystem में शामिल करने वाली सुविधा
  • C++11 ने पुराने तरीकों को छोड़े बिना भाषा की दर्शन और शैली बदल दी, और इस मायने में इसे JavaScript के ES6 जैसा माना गया

आधुनिक C++ ecosystem के विकल्प

  • आधुनिक C++ में वे कई सुविधाएँ हैं जिनकी अपेक्षा लोग दूसरी भाषाओं से करते हैं
  • उदाहरण के तौर पर दिए गए tools और libraries इस प्रकार हैं
  • ecosystem की गुणवत्ता हर क्षेत्र में समान नहीं है, लेकिन कुल मिलाकर इसे JavaScript और Python में मिले अनुभव से बेहतर आंका गया है
  • खासकर FTXUI और STL को अच्छे design और usability के उदाहरण के रूप में गिना गया है

“मज़ा” बनाने वाली व्यापक implementation क्षमता

  • C++ मज़ेदार सिर्फ इसलिए नहीं है कि उसमें आधुनिक सुविधाएँ जुड़ गई हैं, बल्कि इसलिए भी कि इसमें लगभग कुछ भी बनाया जा सकता है
  • desktop apps fenster, SFML, Qt के साथ, या सीधे OS API को संभालकर बनाए जा सकते हैं
  • sound के लिए SFML जैसे तेज़ विकल्पों से लेकर Wwise जैसे commercial tools तक व्यापक दायरा है
  • 3D graphics के लिए OpenGL, Vulkan, Direct3D, Ogre3D जैसे कई विकल्प हैं
  • math के क्षेत्र में BLAS, Eigen, GMTL जैसी libraries हैं
  • अगर ज़रूरी library न भी हो, तो C या C++ ABI और operating system API तक सीधे पहुँचकर चीज़ें बनाई जा सकती हैं, और यह हाथ से बनाने की प्रक्रिया खुद मज़े का हिस्सा बन जाती है

ट्रेंड से बाहर भाषा की रचनात्मक आज़ादी

  • C++ भाषा और ecosystem की गुणवत्ता ऊँची होने के बावजूद इस समय ट्रेंडिंग भाषा नहीं है, इसलिए इसे बिगाड़ देने वाली किस्म की दिलचस्पी भी कम मिलती है
  • C++ community को ऐसी जगह के रूप में चित्रित किया गया है जहाँ आप जो चाहें, उस पर बहुत ज़्यादा दखल नहीं दिया जाता
    • matrix library, GUI library, game engine, या अजीब खेल जैसे projects आज़ादी से आज़माए जा सकते हैं
  • रचनात्मक काम में पहले आइडिया को बाहर निकालने का चरण और फिर ठंडे दिमाग से उसकी आलोचना करके गुणवत्ता बढ़ाने का चरण, दोनों ज़रूरी होते हैं
  • दूसरी भाषाओं में organization, leadership, और community pressure को रचना के बीच के प्रयोगात्मक चरण में बाधक माना गया है
  • C++ की व्यापक संभावनाएँ और अपेक्षाकृत कम शर्मिंदा करने वाली संस्कृति रचनात्मक अनुभव पैदा कर सकती हैं

cppreference.com की ताकत

  • cppreference.com को अब तक इस्तेमाल किए गए प्रोग्रामिंग भाषा दस्तावेज़ों में सर्वोत्तम स्तर का माना गया है
  • इसकी खूबियाँ इस प्रकार हैं
    • हर keyword और library reference documentation के रूप में व्यवस्थित है
    • अधिकतर प्रविष्टियों में वास्तव में काम करने वाले examples हैं
    • हर feature के साथ यह दिखाया जाता है कि वह किस C++ standard version में आया
    • standard documents और संबंधित reference material से लिंक दिए गए हैं
    • DuckDuckGo-आधारित search box है, इसलिए spelling गलत हो या सटीक term याद न हो, तब भी ढूँढना आसान है
    • Copy elision जैसे महत्वपूर्ण concepts को भी examples के साथ समझाया गया है
  • कमी यह है कि अलग-अलग platforms पर compiler install करने के तरीके नहीं बताए गए हैं
  • C++ compilers और platforms की संख्या बहुत ज़्यादा नहीं है, इसलिए getting started guide जोड़ने की गुंजाइश है

C++ की अब भी बाकी समस्याएँ

  • इसका मतलब यह नहीं कि C++ एक परिपूर्ण भाषा है; दूसरी भाषाओं की तरह इसमें भी कई असुविधाएँ हैं
  • Windows पर Microsoft के बाहर के install paths के साथ compiler और development tools को सेट करना कठिन है, और इसके लिए PowerShell install scripts खुद बनाई गईं
  • अभी महसूस की जाने वाली मुख्य असुविधाएँ इस प्रकार हैं
    • compiler error messages का 95% से अधिक हिस्सा उद्योग के सबसे खराब स्तर का माना गया है
    • build tools का उपयोग कठिन है, और Meson में installed package निर्देशों को अनदेखा कर टूटी हुई system libraries इस्तेमाल करने जैसी समस्या भी आई
    • compiler vendors को standard का पालन करवाने के लिए पर्याप्त प्रोत्साहन नहीं है
    • C++ इतिहास की वजह से बहुत जटिल है, और पुरानी heap allocation/raw pointer शैली, template metaprogramming शैली, C++11 के बाद की stack-केंद्रित शैली, और struct-केंद्रित नई शैली एक साथ मौजूद हैं
    • RAII कई व्यावहारिक configuration स्थितियों में बाधा बनती है, और दूसरी भाषाओं जैसी initialization constructors तथा मौजूदा RAII के बीच किसी मध्य बिंदु की ज़रूरत महसूस होती है
  • इन कमियों के बावजूद C++ की असुविधाएँ इतनी नहीं हैं कि मज़ा ही खत्म कर दें, और C++ अब केवल पुराने angle brackets और pointers वाली भाषा जैसा नहीं रह गया है
  • FTXUI GUI layout code इसका उदाहरण है कि अगर कोई न बताए कि यह C++ है, तो इसकी आधुनिक syntax किसी दूसरी भाषा जैसी लग सकती है

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

1 टिप्पणियां

 
GN⁺ 2024-12-25
Hacker News की राय

  • मैं C++ से नफ़रत करने वालों के काफ़ी करीब हूँ, लेकिन वजह यह है कि मुझे भरोसेमंदता मांगने वाले प्रोडक्शन कोड में, और पूरी तरह भरोसे के काबिल न लगने वाले सहकर्मियों के साथ, C++ संभालना पसंद नहीं है
    निजी प्रोजेक्ट्स में यह अब तक मेरे सबसे संतोषजनक coding environments में से एक रहा है, और execution को बेहद बारीकी से control कर पाना सच में रोमांचक है
    करीब 10 साल पहले मैंने C++ छोड़ दिया था और लौटने का इरादा नहीं है, लेकिन आजकल मेरे प्रोजेक्ट्स में long-term reliability सबसे अहम है, इसलिए Rust + CI/CD बिल्कुल फिट बैठता है
    फिर भी यह रोमांच याद आता है कि program को ठीक उसी तरह चलने के लिए design और implement करूं जैसा मैंने सोचा है, और यह मेरी expertise और insight की वजह से हो
    क्या मैं चाहूंगा कि मेरे साथ काम करने वाले लोग इसी motivation से चलें? बिल्कुल नहीं, लेकिन व्यक्तिगत तौर पर यह अविस्मरणीय मज़ा है
    build system और package management एक दुःस्वप्न हैं, preprocessor किसी sadistic मज़ाक जैसा है, syntax भयानक है, और runtime में अपने ही पैर पर machine gun न चला बैठें इसके लिए वर्षों का अनुभव मांगने वाला बहुत सारा कचरा मौजूद है
    लेकिन एक अर्थ में यही तकलीफ़ उस खुशी को और बढ़ा देती है, जब आखिरकार होशियारी और खून-पसीने में लिपटा executable बाहर निकलता है

    • C++ के बारे में पढ़े गए वर्णनों में यह सबसे ज़्यादा relatable में से एक है
      मैंने कई साल काम में C/C++ इस्तेमाल किया है और वापस नहीं जाना चाहता
      दूसरों का code debug करने, अस्पष्ट integration issues झेलने, और build system spaghetti चलाने में बहुत ज़्यादा समय गया
    • काम भी personal projects जितना मज़ेदार होना चाहिए
      लगता है पिछले 10 सालों में tech industry ने यह सोच खो दी है, और मैं इसका दोष बड़ी tech companies को देता हूँ, जो बेहतरीन लोगों को अच्छे खाने और मुलायम कुर्सियों वाली adult prisons में डाल देती हैं
      startups भी कम मज़ेदार हो गए हैं, और VC industry ने सोच की खिड़की को संकरा किया है, जिससे एक जैसी चीज़ें बनाने वाले clone startups और trends बहुत बढ़ गए हैं
      हर नए project में C++ इस्तेमाल करने की वजह यह भरोसा है कि जब कुछ खुद बनाना पड़े, तो मैं बना सकता हूँ
      frameworks अक्सर, खासकर project के core को संभालते समय, मेरे मनचाहे तरीके से behave नहीं करते, इसलिए उन्हें लगातार इस्तेमाल करना नहीं चाहता
      अगर खुद बना सकते हो तो खुद बनाओ, नहीं तो framework इस्तेमाल कर लो
      अगर आप खुद बना सकते हैं, तो C++ कुछ भी कर सकता है और अहम तरीकों से रास्ते में नहीं आता—एक शानदार tool है
      Rust जैसी languages शिकायत कर सकती हैं कि मैं खतरनाक काम कर रहा हूँ, लेकिन C++ में मैं अपने दिमाग के model को सीधे express कर सकता हूँ
      कभी-कभी मैं pointers में सोचता हूँ, और pointers सच में अच्छे tools हैं
      मज़ा वापस लाएँ, सिर्फ निजी जीवन में नहीं बल्कि काम में भी

  • यह लेख कुछ हद तक उलझा हुआ लगता है
    इसमें कई बातें कही गई हैं, लेकिन उनसे यह निष्कर्ष कैसे निकलता है कि C++ ज़्यादा मज़ेदार है या कम, यह निकालना मुश्किल है
    modern C++ को बेहद high quality कहना और साथ ही व्यापक legacy problems और भयानक tools की बात करना भी confusing है
    unique_ptr को शानदार कहना लेकिन RAII को सच में नापसंद करना, और यह दावा करना कि metaprogramming पहले हर जगह था लेकिन अब नहीं है, भी अजीब है
    concepts देखें तो ऐसा नहीं लगता; और यह कहना कि C++ के पास सबसे अच्छी graphics libraries हैं या Python install करना C++ से मुश्किल है, लेखक की ऐसी धुन लगती है जिसका मुख्य तर्क से ज़्यादा लेना-देना नहीं है
    आखिरकार लगता है कि लेखक निजी कारणों के एक जटिल मिश्रण की वजह से C++ को मज़ेदार मानता है, और अपने-आप में इसमें कोई समस्या नहीं है
    performance और technical nature की वजह से मैंने भी C++ में सबसे मज़ेदार programming की है, लेकिन real-world software development में C++ उन तमाम वजहों से अच्छा नहीं है जिन्हें हम जानते हैं
    C++ दशकों की legacy और politics से घायल, गहरे विरोधाभासों वाली language है, और C++ की reality को नज़रअंदाज़ करना C++ discussions में सबसे बड़ी गलती है
    आजकल C++ के प्रति मेरा attitude थकान जैसा है, और पिछले कई सालों में C++ ने जो obstacles फेंके हैं, उन्हें अब और पार नहीं करना चाहता
    बहुत पहले मर चुके घोड़े को लगातार पीटने की ज़रूरत नहीं है; C++ को बस C++ रहने दिया जाए

    • मुझे लगता है वह वाक्य लेख का सार अच्छी तरह समेटता है
      मेरी नज़र में लेख उलझा हुआ नहीं, बल्कि लेखक आनंद ले रहा है और उस खुशी को जितना हो सके बांटना चाहता है
      यह किसी proper opinion piece से ज़्यादा actively persuade करने वाला लेख नहीं है; बल्कि “अगर बिना समझाए ही बात जमती है, तो शायद तुम्हें भी मज़ा आए” जैसा है
      अगर आप commercial work में reality से पिट-पिटकर थक चुके हैं, तो इसका बेतुका लगना पूरी तरह समझ आता है
      मैं भी आजकल, अजीब बात है, JavaScript लिखते हुए बहुत मज़ा ले रहा हूँ; अगर मैं ऐसा ही लेख लिखूँ तो पिछले 10 सालों में commercial JavaScript से थके लोगों को वह उतना ही खराब लगेगा
      फिर भी अच्छा लगा कि लेखक को मज़ा आ रहा है, और उसने वह मज़ा share करने का फैसला किया

  • C++ project में third-party dependency को Linux/Windows/macOS पर चलने लायक static link करने में मैंने 3 दिन लगाए
    वह package conan/vcpkg में नहीं था, सिर्फ एक GitHub repository थी जिसमें अजीब सा Makefile/cmake combination था
    मैं cmake/cpp expert से बहुत दूर हूँ, लेकिन अधिकतर modern languages में pip install, cargo add, npm install, go get जैसे तरीकों से यह समस्या नहीं बनती
    C++ semantics की बारीकियाँ किसी किताब में शुरू से आखिर तक पढ़ लेने पर भी, असली project में काम करना फिर भी पीड़ादायक है

    • JavaScript की dependency और build tool chain भी सबसे गंदे Makefile जितनी ही उलझी हुई है
      हैरानी है कि आखिरकार हम JavaScript version of autotools जैसी चीज़ तक पहुँच गए
    • जानना चाहूँगा कि खास तौर पर क्या मुश्किल था
      दूसरे लोगों के code को static build करना या दूसरे platforms पर build होने लायक बदलना कभी-कभी पेचीदा हो सकता है, लेकिन linking अपने-आप में आम तौर पर include directory, library path और library specify करने भर की बात होती है
    • उल्टा देखें तो, अगर इस third-party को किसी दूसरी “modern” language में इस्तेमाल करना हो तो क्या बेहतर होगा, यह सोचता हूँ
      अगर किसी ने vcpkg/conan packaging नहीं की है, तो संभव है कि वह pip/cargo/npm में भी न हो
      C++ में मुश्किल था तो दूसरी languages में यह कहीं ज़्यादा मुश्किल हो सकता है
      हालांकि historical C++ के कुछ हिस्से, खासकर build वाली कहानी, बहुत खराब हालत में हैं—यह यहाँ भी दिखता है
      अगर वह सिर्फ vcpkg में मौजूद हो, तो install करने की difficulty बाकी ecosystems जैसी ही हो जाती है

  • समय-समय पर C की जगह C++ में काम करके देखता हूँ, और हर बार पैटर्न लगभग वही रहता है
    कोई नई C++ technique पता चलती है, लगता है कुछ बेहतर होगा तो code लिखता हूँ, compiler error खाता हूँ, और फिर बाकी दिन यह सीखने में निकल जाता है कि जो मैं चाहता हूँ वह क्यों नहीं कर सकता
    आम तौर पर C++14 तक सीमित रहता हूँ और कुछ समस्याएँ बाद के versions में ठीक हो गई हैं, लेकिन फिर भी बात वही है
    C++ को सच में पसंद करना चाहता हूँ; सिद्धांत में यह productivity बढ़ाने वाला ज़्यादा शक्तिशाली C देता है, लेकिन अंत में cognitive burden इतना ज़्यादा हो जाता है कि आम तौर पर “classes वाला C” लिखकर आगे बढ़ जाता हूँ

    • सीखना मज़ेदार लगने का एक दौर होता है, और लगता है original पोस्ट लिखने वाला अभी वहीं है
      2003 में real-time C++ बहुत लिखा था और उससे नफरत थी, लेकिन पिछले साल code का ज़्यादातर हिस्सा C++ में लिखते हुए आखिरकार यह पसंद आने लगा
      lambda और auto C++ से नफरत न करने का turning point थे
      templates भी थोड़ा इस्तेमाल किए, लेकिन मुख्यतः उसी function की variants में ढेर सारी branches न लिखनी पड़ें इसलिए
      lambda की वजह से SICP vibes वाले Lisp-family teachers से पहली बार सीखे तरीके से code लिख पाना संभव हुआ
      unique_ptr इस्तेमाल करने पर allocation भी बुरा नहीं लगा
    • ऐसे लोगों का बहुत खराब code देखा है जिन्होंने अभी-अभी कोई feature सीखा और बस उसे इस्तेमाल करना चाहा
      ऐसा न करें; पहले सोचें कि code का इस्तेमाल कैसे होगा, फिर अगर कोई feature समस्या हल करता है तो उसे इस्तेमाल करें
      समस्या → समाधान होता है, उल्टा नहीं
      उदाहरण के लिए C++ templates कुल मिलाकर डरावने हैं, लेकिन compile-time duck typing या sizeof() आधारित padding अपने-आप जोड़ना जैसी चीज़ें कभी-कभी बहुत उपयोगी होती हैं
    • मेरा C++ अनुभव भी ठीक ऐसा ही था
      शुरुआत में मैं C# programmer था और embedded project की वजह से C सीख रहा था, और flow बिल्कुल वही था
      C++ में बहुत से शानदार features हैं जो application से बिल्कुल fit बैठें तो powerful लगते हैं
      लेकिन जब भी कोई नया feature आज़माता, मैं जो करना चाहता था वह हमेशा उस context में काम न करने वाला edge case निकलता, और घंटों या दिनों तक कोशिश करने के बाद हार मानकर बस C में लिख देता
    • C++ भी ज़्यादातर technologies की तरह, उसे ठीक से सीखने की मेहनत करो तो बेहतर काम करता है
      हाँ, Python या Ruby जैसी कुछ languages इस trend से बाहर भी हैं
    • ChatGPT या Copilot ऐसी चीज़ों में काफी मदद करते हैं
      आम तौर पर error text copy करके उससे decode करवाता हूँ

  • C++ सच में मज़ेदार है, और मुझे लगता है लोगों की शिकायतें context पर बहुत निर्भर करती हैं
    कई C++ developers language से नफरत करते हैं, लेकिन असल में वह नफरत कई बार गलत दिशा में होती है
    अक्सर वे ऐसे legacy product से जूझ रहे होते हैं जिसे उन लोगों ने बनाया था जो software का बहुत अच्छा इस्तेमाल नहीं करते थे
    मेरे साथ Rust में भी कुछ ऐसा ही हुआ; मुझे कंपनी के मौजूदा Rust project में लगाया गया, और पुराने codebase में कई परस्पर टकराने वाली conventions थीं
    ऐसे error-handling types जो ठीक से compose नहीं होते थे, खराब class abstractions, अनावश्यक unsafe blocks वगैरह थे, और वह अब तक किए projects में सबसे कष्टदायक था
    Rust को दोष देना आसान है, लेकिन असल में वह बस खराब software development था
    C++ में खामियाँ हैं, यह सही है, लेकिन लोगों को होने वाला काफी दर्द इसलिए होता है क्योंकि वे खराब code से निपट रहे होते हैं, जो किसी भी language में लिखा हो तो भी गड़बड़ ही होता

    • C को छोड़कर लगभग हर दूसरी language में v[x]=y लिखने पर मनमाने memory corruption को न्योता नहीं दिया जाता
      C++ का std::optional, अगर v खाली हो और आप *v call करें, तो undefined behavior बन जाता है
      optional का मूल उद्देश्य ऐसे value को रखना है जो खाली हो सकती है, तो optional खाली होने पर सबसे आम operation में undefined behavior क्यों डाला गया है, यह समझना मुश्किल है
      C++ बहुत इस्तेमाल करने के अनुभव से समस्या यह है कि project के हर programmer को 100% समय 100% perfect होना पड़ता है
      memory checker और STL debug mode चला सकते हैं, लेकिन अगर release में उन्हें नहीं चलाते, तो उम्मीद करनी पड़ती है कि test suite हर अजीब चीज़ को hit करे जो कोई मूर्ख या दुर्भावनापूर्ण user कर सकता है
      जिस दौर में software इतना महत्वपूर्ण हो गया है, और Rust C++ जैसी performance के करीब दिखता है, तब ऐसी language इस्तेमाल करने लायक है या नहीं जिस की कई basic सुविधाओं को सुरक्षित तरीके से इस्तेमाल करना बहुत कठिन है—यह सवाल उठता है
      ऊपर से यह लगातार और खराब हो रहा है: खाली std::function call assert फेंकता था, लेकिन नया std::copyable_function इसे undefined behavior बना देता है
    • इस बात से सहमत होना मुश्किल है
      type system परेशान करने वाला है, और फिर भी ठीक-ठाक memory safety नहीं मिलती
      most vexing parse सच में vexing है, और pointer decay जैसी C से विरासत में मिली अजीब चीज़ें भी जस की तस हैं
      उसके ऊपर std::array जैसे नए solutions चढ़ा देते हैं, लेकिन पुराने तरीके हटा नहीं पाते
      असली module import system की नकल करने के लिए preprocessor पर लगातार निर्भर रहना भी समस्या है, और उसी वजह से class code organization या pimpl idiom जैसे workarounds आते हैं
      मूल रूप से खामियाँ इतनी बड़ी और इतनी ज़्यादा हैं कि अब उसके भीतर की खूबसूरती ढूँढना मुश्किल है
    • बात सही है, लेकिन language जितनी जटिल होती है, उतना ही आसान होता है ऐसा अव्यवस्थित code बनाना जिसे समझना नामुमकिन हो
      दूसरी ओर, सरल blub language project codebase की हालत चाहे जैसी हो, आम तौर पर काफी आसानी से समझ में आ जाता है
    • पुराना है, लेकिन काफी मज़ेदार C++ FQA देखने लायक है: https://yosefk.com/c++fqa/

  • अच्छा है कि किसी को C++ में आनंद मिलता है, लेकिन व्यक्तिगत रूप से 20 साल से ज़्यादा झेलने के बाद अब मेरे लिए C++ खत्म करना ही ठीक है
    यह बस गड़बड़ है
    अगर सचमुच low-level control चाहिए तो खामियों के बावजूद C से काम चला लूंगा, वरना Rust, Python वगैरह मुझे कहीं ज़्यादा खुश रखते हैं

    • सहमत
      फिर भी C++ बना रहेगा
      इस भाषा में लिखा code बहुत ज़्यादा है, इसे पक्का सीख लेना निश्चित रूप से अच्छा skill है, और इसमें बहुत पैसे वाली नौकरियां भी हैं
      मेरे लिए भाषा बहुत बाधा बनती है और हद से ज़्यादा जटिल लगती है
      मुझे यह narrative पता है कि “modern C++” शानदार है, पुराने versions सीखने की ज़रूरत नहीं, और हर नए version के साथ यह और सरल हो रही है
      समस्या यह है कि असल में जो codebase आपके हाथ आता है, वह modern C++ नहीं होता
      उसमें अब तक आए सारे features इस्तेमाल हो रहे होते हैं, वह कठिन होता है और traps से भरा होता है
      जो लोग सालों से अपने ही project में C++ कर रहे हैं, वे कुछ expertise बनाकर complexity के प्रति immune हो सकते हैं, लेकिन यह सचमुच अच्छी भाषा नहीं है
    • समय के साथ C++ को कुछ ज़्यादा सहने लायक बनाने वाली चीज़ों में से एक यह है कि ज़्यादातर हिस्सों को ऐसे implementation से naturally replace करना आसान हो गया है, जो आपके सोचे हुए तरीके से behave करता है और जिसका behavior पर्याप्त रूप से defined है
      जैसे core data types, standard library वगैरह बदलना
      खासकर C++20 के बाद replacement का आधार काफी native और expressive महसूस होता है
      मैं जितने नए C++ projects देखता हूं, उनमें से काफी इस दिशा को मजबूती से अपनाते हैं
      applications के लिए system-level domain-specific language आसानी से बना पाना C++ की ताकत है
    • C++/SDL2 में बना रहे Ultima-derived project में मैंने C++ features में से बस कुछ ही लिए थे
      अफसोस कि उसे पूरा नहीं कर पाया, लेकिन याद है कि classes, std::function, std::unordered_map, std::string, std::unique_ptr जैसी चीज़ें थीं
      समान style न हो तो किसी और का code पढ़ना कल्पना करना भी मुश्किल है
      बड़े programs को पेशेवर रूप से न लिखने की वजह से Visitor pattern जैसे programming patterns से आगे बढ़ना सबसे कठिन था
      काश C++ C++11 पर ही रुक गया होता
      committee अब लगता है हर चीज़ language में डालना चाहती है, और C++ हर niche programming style को support करने वाली एक super-giant language जैसा दिखता है
    • C++ पूरी तरह गड़बड़ है
      लेकिन मज़ेदार गड़बड़ है, और मुझे C++ में लिखना पसंद है
      कभी-कभी यही महत्वपूर्ण होता है
      Rust के साथ रिश्ता कहीं ज़्यादा ठंडा है
      मैं Rust का सम्मान करता हूं, और खासकर काम जैसी context में जहां C++ के इस्तेमाल का बचाव करना मुश्किल हो, अगर Rust सही लगे तो उसे इस्तेमाल करता हूं, और मानता हूं कि Rust जो कर रहा है वह महत्वपूर्ण है
      लेकिन अब तक काफी Rust projects करने के बावजूद उसमें लिखना उबाऊ लगता है
      बुनियादी पहलुओं में वह बेहतर है, लेकिन कम से कम मेरे लिए कम आनंददायक है
    • क्या Rust भी C जैसी control और low-level nature देने की कोशिश करने वाली भाषा नहीं है?
      unsafe की seal खोल दें तो integers को pointers में explicitly cast कर सकते हैं, और उदाहरण के लिए memory-mapped I/O से hardware control भी कर सकते हैं, नहीं?

  • यह लेख बड़े दायरे वाला लंबा rant है, और “C++” शब्द भर से लोग trigger होकर इसके कई हिस्सों को ignore कर सकते हैं
    मैं भी कभी-कभी ऐसा करता हूं
    शिकायतें देखनी हों तो “It's Not All Puppies and Butterflies” वाले हिस्से पर कूद जाएं
    लेखक C++11 से बहुत प्रभावित हुआ था, और लगभग 20 साल तक जानबूझकर C++ को ignore करने के बाद मुझे भी कुछ ऐसा ही लगा
    खेलने लायक packages और libraries का परिचय कराना अच्छा है, लेकिन फिर भी किसी और library को अपने project में डालना अक्सर दर्दनाक होता है
    single-file header याद आता है
    FTXUI दिलचस्प है
    और सच में cppreference.com कमाल है
    Python docs भी काफी अच्छे हैं, लेकिन cppreference.com जितने अच्छे docs मैंने नहीं देखे

    • cppreference.com अपने नाम की तरह reference docs के रूप में बहुत शानदार है
      Python docs इधर-उधर बिखरे हैं, कई जगह अधूरे हैं, और उनमें consistent prose editing style की भी कमी है
      लेकिन Diataxis framework के हिसाब से वे सिर्फ reference docs नहीं, बल्कि कई तरह के docs को काफी अच्छी तरह cover करते हैं
      उन docs को लिखने वाले लोग इस framework को स्पष्ट रूप से ध्यान में रखते हुए improvement की दिशा खोजते हैं
      फिर भी यह code development की तरह ही चलने वाला volunteer-based open source काम ही है
    • स्कूल और university में C++ सीखने के बाद मैं सीधे काम में Python/JavaScript पर चला गया था, लेकिन इस लेख की वजह से C++ के बहुत से ऐसे हिस्से भर गए जिनके बारे में मुझे पता नहीं था
      कुछ समय से “system के और करीब” जाना चाहता था, और साथ-साथ Rust सीखना भी आसान नहीं था
      यह लेख देखकर उम्मीद जगी कि शायद C++ फिर से सीखकर यह हो सके
      नमस्ते CMake… नहीं, शायद Meson कहना चाहिए

  • अगर कोई talented team modern C++ का अच्छा इस्तेमाल जानती हो और नया project शुरू करे, तो मैं मानता हूं कि C++ शानदार है
    यह मज़ेदार और powerful language है, performance अच्छी है, और complex होने के बावजूद debugging और optimization अपेक्षाकृत intuitive हैं
    मुझे लगभग 5 साल पुराने codebase पर काम करने का मौका मिला था, जो C++11 के बाद के standards के हिसाब से लिखा गया था, और लेख में बताए कई कारणों से वह बहुत enjoyable था
    इसके उलट 20–30 साल में evolve हुआ पुराना codebase, या ऐसा codebase जिसे कुशल लोगों ने maintain न किया हो, बिल्कुल अलग अनुभव होगा

    • developer life मैंने PHP से शुरू की थी, custom WordPress themes बनाते हुए जिनमें special data types के लिए plugins थे, और काम करते-करते सीखा
      21 साल की उम्र में company ने tuition fees देने की पेशकश की, तो मैं computer science degree program में वापस गया, और बाद में इसे computational science में बदल दिया
      “Introduction to Programming” class के पहले दिन C++ छूते ही मुझे उससे प्यार हो गया
      उस समय इस्तेमाल कर रहे PHP 7 की तुलना में type system, debugging, ecosystem शानदार थे
      manager की अनुमति लेकर मैंने existing intranet apps के कुछ हिस्सों के लिए C++-based API बनाई, जिसे PHP websockets से call करता था, और type system व performance का फायदा उठा पाया
      वे systems आज भी company भर में रोज़ इस्तेमाल होते हैं, और maintenance भी समस्या नहीं रही
      यहां तक कि वे IBM Pase for i नाम के काफी अनोखे environment में चल रहे हैं, फिर भी
      अब Rust और Axum आज़माने के बाद ऐसे API बनाते समय मैं Rust ecosystem को कहीं ज़्यादा prefer करूंगा, लेकिन C++ भी recognition deserve करता है
      खासकर अगर आप TypeScript नहीं बल्कि JavaScript या PHP जैसी web languages से आ रहे हों, तो यह सचमुच बेहतरीन language है
    • 20–30 साल में evolve हुए या कुशल लोगों द्वारा maintain न किए गए पुराने codebase की condition में, मुझे कोई ऐसी दूसरी language याद नहीं आती जो डरावनी न हो
      सच कहूं तो जो कई possibilities दिमाग में आती हैं, जैसे C, Java, Fortran, उनकी तुलना में शायद मैं C++ को prefer करूंगा
      exception C# हो सकता है, लेकिन पता नहीं वह इतनी पुरानी होने की condition में आता भी है या नहीं

  • C++ में built-in regular expressions आए और कहा गया कि वे काफ़ी अच्छे हैं, लेकिन std::regex को अच्छा कहना मुश्किल है
    इसकी performance खराब है और Unicode support भी कमज़ोर है, इसलिए आम तौर पर इससे बचना बेहतर है

    • हमारी कंपनी में इस्तेमाल होने वाला linter भी std::regex न इस्तेमाल करने को enforce करता है
    • सोचता हूँ कि क्या specification में ही कोई ऐसी समस्या है जो performance गिराती है

  • मैंने C++ सीखा भी है और इसका आनंद भी लिया है, लेकिन बहुत गहराई में नहीं गया
    मुझे हमेशा C ज़्यादा पसंद रहा, और मूल Dune game engine या Unix utilities जैसी बेहतरीन codebases भी बहुत हैं जिन्हें C बेहतर सीखने के लिए पढ़ा जा सकता है
    हाल में Rust को थोड़ा आज़माया, तो C++ इस्तेमाल करने की कोई बहुत मज़बूत वजह नज़र नहीं आती
    functional programming से प्रेरित powerful type system और performance का combination हराना मुश्किल लगता है, और यह लगभग perfect language जैसा लगता है
    फिर भी C++ इस्तेमाल करने की legacy वजहें निश्चित रूप से होंगी
    शायद game engines, embedded programming, या किसी और तरह की legacy coupling जैसी चीज़ें

    • काम में मैं C++ और Rust दोनों के बीच switch करता हूँ, और ईमानदारी से कहूँ तो modern C++20/23 में Rust को काफ़ी हद तक copy करने के तरीके से कई pain points ठीक हो रहे हैं
      नया C++ codebase हो तो उसे काफ़ी साफ़-सुथरा बनाया जा सकता है
      लेकिन इस समय कोई नया software C++ में क्यों बनाएगा, यह मुझे ठीक से समझ नहीं आता
      C++ में परेशान करने वाली चीज़ें बहुत हैं
      library/package management standardised नहीं है, headers code duplication हैं, और standard library implementation पर निर्भर करती है और लगभग पढ़ने लायक नहीं होती
      standard में अजीब behaviours हैं, लोग undefined behavior पर निर्भर रहते हैं और उन्हें पता भी नहीं होता, use-before-allocation की समस्याएँ होती हैं, ownership issues और गलत reference counts की वजह से subtle memory leaks होते हैं
      हर चीज़ को default के बजाय const बनाना पड़ता है, noexcept guarantee करने के लिए आपको हर called चीज़ के exceptions जाँचने पड़ते हैं, और standard library operations में errors पढ़ना मुश्किल होता है
      भारी object-oriented code असल में technical debt है
      C++ का LSP Rust की तरह abstract syntax tree देखकर definitions खोजने वाली structural approach वाला नहीं है, इसलिए navigation और codebase समझना धीमा होता है
      Rust nostd को first-class तरीके से explicitly support करता है, लेकिन C++ में standard library बंद करने के लिए compiler-specific flags चाहिए और यह verify करना मुश्किल है कि आपने सही किया या नहीं
      इसलिए embedded की वजह से C++ इस्तेमाल करने वाली दलील मुझे बहुत convincing नहीं लगती
      Rust में भी bevy जैसे game engines हैं, लेकिन वे अभी नए हैं, और चाहें तो Godot scripting में Rust भी जोड़ सकते हैं
      low-level audio भी Rust में उतना ही आसान है, और एक single crate से cross-platform handling संभव है
      कुल मिलाकर मुझे लगता है कि मुख्य बात legacy code और बदलाव को लेकर झिझक है
    • Legacy सिर्फ C++ में लिखे apps तक सीमित नहीं, बल्कि कई dimensions में बहुत विशाल है
      इसमें users की संख्या, प्रकाशित और उपलब्ध knowledge और resources, books, lectures, blogs, articles, videos, software libraries, और C नाम की एक और विशाल language के साथ high compatibility तक शामिल हैं
      जो लोग इस क्षेत्र में कुछ साल से ज़्यादा रहे हैं, उनके लिए यह software industry की common sense जैसी बात है
      मैंने C++ बहुत ज़्यादा इस्तेमाल नहीं किया, इसलिए खुद को ठीक से beginner भी नहीं कह सकता, लेकिन पहले language creator Bjarne Stroustrup, Scott Meyers वगैरह की classic C++ books खरीदकर पढ़ी थीं और कुछ हद तक समझी थीं
      हालांकि C को मैंने सफल commercial products सहित कई साल production में खूब इस्तेमाल किया है
      https://www.stroustrup.com/applications.html
      https://www.stroustrup.com
      https://en.m.wikipedia.org/wiki/Bjarne_Stroustrup
      https://en.m.wikipedia.org/wiki/Scott_Meyers
    • जब low latency चाहिए लेकिन correctness की बहुत चिंता नहीं होती, तब C++ समझ में आता है
      इसलिए मुझे लगता है game development सबसे लंबे समय तक C++ में बना रहेगा
      अगर 0.001% users के लिए segmentation fault से game crash हो जाए, तो रवैया कुछ ऐसा होता है कि तो क्या हुआ
    • high-frequency trading भी एक संभावना है