22 पॉइंट द्वारा GN⁺ 2026-03-31 | 7 टिप्पणियां | WhatsApp पर शेयर करें
  • C++26 आधिकारिक रूप से तकनीकी रूप से पूरा हो गया है. इसमें reflection, memory safety सुधार, contracts, std::execution जैसी चार प्रमुख क्षमताएँ शामिल हैं
  • compile-time reflection को templates के आने के बाद C++ इतिहास का सबसे शक्तिशाली abstraction engine बताया जा रहा है, जिससे भाषा खुद को वर्णित कर सकती है और code generate कर सकती है
  • मौजूदा C++ code को C++26 में सिर्फ recompile करने भर से uninitialized local variables के undefined behavior (UB) की पूरी श्रेणी हट जाती है, और मजबूत standard library के साथ bounds safety सुनिश्चित होती है
  • Google में तैनाती के नतीजों के अनुसार, 1,000 से अधिक bugs ठीक हुए और production environment में segfaults 30% कम हुए
  • GCC ने reflection और contracts को पहले ही trunk में merge कर दिया है, इसलिए compiler implementations द्वारा तेज़ adoption की उम्मीद है

C++26 पूरा: C++11 के बाद सबसे महत्वपूर्ण रिलीज़

  • UK के London Croydon में हुई ISO C++ committee meeting में C++26 पर तकनीकी काम अंतिम रूप से पूरा हो गया
    • लगभग 210 लोग शामिल हुए (130 प्रत्यक्ष, 80 Zoom से), और 24 देशों के आधिकारिक प्रतिनिधियों ने भाग लिया
    • गर्मियों में प्राप्त 411 international comments (CD चरण) को संभालने में बैठक का अधिकांश समय लगा
    • नई सुविधाएँ जोड़ने या हटाने के बजाय अंतिम polishing और quality पर ध्यान दिया गया
  • इस बैठक में पूरा हुआ C++26 अब international approval ballot (DIS) के लिए अंतिम दस्तावेज़ीकरण चरण में प्रवेश कर चुका है

C++26 की 4 प्रमुख क्षमताएँ

(1) reflection

  • templates के आविष्कार के बाद से इसे C++ विकास इतिहास का सबसे बड़ा अपग्रेड कहा जा रहा है; यह भाषा को खुद का वर्णन करने और code generate करने की क्षमता देता है
  • जून 2025 में C++ committee ने compile-time reflection को C++26 draft में शामिल कर भाषा के इतिहास में एक बड़ा मोड़ दर्ज किया
  • इसे "efficient abstractions को व्यक्त करने के लिए सबसे शक्तिशाली नया engine" कहा गया, और यह भी कि इस रॉकेट से क्या-क्या संभव है, यह खोजने में अगले 10 साल लग सकते हैं

(2) memory safety सुधार

  • सिर्फ recompile करने से मौजूदा C++ code में uninitialized local variables को पढ़ने से जुड़ी UB (undefined behavior) की पूरी श्रेणी C++26 में हट जाती है
  • Hardened Standard Library को standardize किया गया है, जो vector, span, string, string_view जैसे प्रमुख types के लिए bounds safety सुनिश्चित करती है
    • performance overhead औसतन 0.3% (1% से कम) मापा गया
    • Apple platforms और Google services में इसे पहले ही सैकड़ों मिलियन lines of code पर तैनात किया जा चुका है
  • Google deployment के परिणाम:
    • 1,000 से अधिक bugs ठीक किए गए
    • सालाना 1,000~2,000 bugs की रोकथाम की संभावना
    • पूरे production में segfault दर 30% कम
    • Google के कुल C++ codebase में पूरी तरह opt-out करने वाली services सिर्फ 5, और unsafe access API के उपयोग के मामले केवल 7

(3) contracts: pre, post, contract_assert

  • C++26 में language-level contracts जोड़े गए — function declarations में precondition, postcondition और assertion statements का समर्थन
  • इसे C के assert macro से कहीं अधिक शक्तिशाली माना जा रहा है
  • contracts अपनाने पर मतदान के नतीजे:
    • फ़रवरी 2025 (working draft merge): समर्थन 100, विरोध 14, निरपेक्ष 12
    • मार्च 2026 (C++26 अंतिम स्वीकृति): समर्थन 114, विरोध 12, निरपेक्ष 3
  • committee के कुछ विशेषज्ञों की तकनीकी चिंताएँ बनी रहीं, लेकिन तीन बैठकों और कई conference calls में इस पर पर्याप्त चर्चा हुई
  • नवंबर 2025 से पहले की बैठकों में feedback के आधार पर contracts specification की 2 bugs ठीक की गईं

(4) std::execution (Sender/Receiver)

  • यह C++ का asynchronous model है, जो concurrency और parallelism को व्यक्त और नियंत्रित करने के लिए एक unified framework देता है
  • structured concurrency (जहाँ lifecycle सख्ती से nested होता है) को आसानी से लिखने योग्य बनाकर यह data races को संरचनात्मक रूप से रोकने वाली safety विशेषता देता है
  • ध्यान दें: फिलहाल documentation कम है और "fingers-and-toes" libraries पर्याप्त नहीं हैं, इसलिए इसका adoption अन्य C++ features की तुलना में कठिन हो सकता है
    • किसी अनुभवी विशेषज्ञ की मदद और मौजूदा asynchronous code के साथ integration के लिए adapter libraries लिखने की ज़रूरत पड़ सकती है

C++26 के तेज़ adoption की उम्मीद क्यों है

  • यह C++11 के बाद सबसे अधिक मांग वाला feature set है, क्योंकि इसमें reflection और safety improvements शामिल हैं जिन्हें अधिकांश C++ developers रोज़मर्रा में इस्तेमाल करेंगे
    • C++17, C++20, C++23 के parallel STL, concepts, coroutines, modules आदि को सभी C++ developers पर C++11 जितना व्यापक प्रभाव डालने वाला नहीं माना गया
  • GCC और Clang ने C++26 के विकास के दौरान लगभग दो-तिहाई features पहले ही pre-implement कर रखे थे
    • GCC ने reflection और contracts को trunk में merge कर दिया है और release की तैयारी में है

C++29 पर काम शुरू: memory safety को और गहरा करना

  • इस बैठक में C++29 schedule भी अपनाया गया, जिससे 3-वर्षीय release cycle जारी रहेगी
  • C++29 का मुख्य फोकस type और memory safety को और मज़बूत करना तय किया गया
    • undefined behavior (UB) को और कम करने वाले प्रस्तावों की समीक्षा चल रही है
    • SG23 (safety/security subgroup) में Bjarne Stroustrup की P3984 type safety profile और Gabriel Dos Reis के general profile framework के आधार पर काम चल रहा है
  • Apple के Oliver Hunt ने P4158R0 "C++ Subsetting and Restriction for Memory Safety" प्रस्तुत किया
    • WebKit के 40 लाख से अधिक lines of code पर subset-of-superset approach लागू की गई
    • रिपोर्ट के अनुसार यह "कई vulnerability classes को रोकती है, और मौजूदा policy अतीत के अधिकांश exploits को रोक सकती थी"
  • memory safety विषय पर committee के आधे से अधिक सदस्यों की मौजूदगी वाले बुधवार शाम सत्र और लगभग 90 लोगों वाले शुक्रवार दोपहर EWG-only सत्र में गहन चर्चा हुई
  • quantities and units library (P3045R7 "Quantities and units library") SG6 और SG18 से आगे बढ़कर LEWG (main library evolution subgroup) तक पहुँची

आगे की समय-सारिणी

  • अगली दो बैठकें Brno, Czech Republic (जून) और Búzios, Rio de Janeiro, Brazil (नवंबर) में होंगी
  • इन दोनों बैठकों में C++29 working draft में features जोड़ने का काम शुरू होगा
  • अभी से अगली बैठक तक कई subgroup telecons (वीडियो मीटिंग्स) पहले ही schedule में शामिल हैं

7 टिप्पणियां

 
roxie 2026-04-02

zzz

 
GN⁺ 2026-03-31
Hacker News की राय
  • यह निराशाजनक है कि C++ में Contracts फीचर को standard में अपनाया गया
    ऐसा लगता है कि जो भाषा पहले ही जटिलता की सीमा तक पहुँच चुकी है, उसमें एक और परत जोड़ दी गई है
    Bjarne Stroustrup ने भी इस फीचर को "अधूरा और committee-style में फुलाया गया design" कहा था
    मुझे लगता है कि इस फीचर में खुद कई जोखिम भरे पहलू (footguns) हैं, इसलिए इसकी पर्याप्त ठोस वजह नहीं बनती

    • 90 के दशक की शुरुआत में मैंने खुद C++ में Contracts extension implement किया था
      लेकिन किसी ने उसमें रुचि नहीं दिखाई
      संबंधित सामग्री यहाँ है
    • बहुत से लोग कहते हैं कि “C++ बहुत complex है”, लेकिन दिलचस्प बात यह है कि हर व्यक्ति के दिमाग में आने वाले complex features अलग-अलग होते हैं
    • हो सकता है C++ के Contracts का design गलत हो, लेकिन मुझे लगता है कि यह concept खुद भाषा के विकास के लिए ज़रूरी है
      Ada या Rust की तरह formal verification (proof assistant) के साथ integration करके यह testing की जगह static verification संभव बनाने वाला मुख्य तत्व है
      Ada Spark को देखना उपयोगी हो सकता है
    • Contracts पर documentation बहुत भ्रमित करने वाला है
      cppreference documentation का पहला example उल्टे state बदलने वाला exceptional case है
      syntax भी intuitive नहीं है
      उदाहरण के लिए asserts_pre(num >= 0) जैसा रूप pre(num >= 0) से कहीं अधिक स्पष्ट होता
      लेकिन लगता है कि brevity को प्राथमिकता दी गई है
    • Contracts दरअसल उस काम का standardization हैं जो C++ developers पहले से अनौपचारिक रूप से करते आ रहे थे
      यह जटिलता बढ़ाने से ज़्यादा, अलग-अलग implementations को एक साथ लाकर interoperability बढ़ाने की दिशा है
      बल्कि Reflection जैसे features मुझे उससे अधिक जटिलता जोड़ते दिखते हैं
  • C#, Java developer होने के नाते एक सवाल है
    मैं जानना चाहता हूँ कि आजकल C++ से किस तरह की applications बनाई जाती हैं
    असल में यह किन समस्याओं को हल करता है, यह सुनने का मौका बहुत कम मिलता है

  • uninitialized variables के “erroneous behavior” की पुनर्परिभाषा दिलचस्प है
    standard document के अनुसार इससे runtime cost आती है,
    और [[indeterminate]] attribute का उपयोग करके इसे फिर से undefined behavior में बदला जा सकता है

    int x [[indeterminate]];
    std::cin >> x;
    
    • D भाषा सभी variables को अपने-आप initialize करती है
      अगर सचमुच initialize नहीं करना हो, तो int x = void; की तरह स्पष्ट रूप से लिखना पड़ता है
      गलती से ऐसा लिख देने की संभावना लगभग नहीं होती
    • document को जल्दी से पढ़कर दो बातें चौंकाने वाली लगीं
      1. “स्वतंत्र रूप से निर्धारित मान” से ठीक-ठीक क्या मतलब है — 0 से भरना, या memory का कोई random value?
      2. [[indeterminate]] फिर से UB(Undefined Behavior) पर क्यों लौट जाता है, यह सवाल है
    • शायद इस फीचर को compiler flag से नियंत्रित किया जा सकेगा
      कुछ projects अब भी manual initialization को पसंद करेंगे
    • बाद में code में [[indeterminate]] देखने वाले लोगों के बारे में सोचकर ही डर लगता है
      आखिरकार वे इसका मतलब ढूँढने में समय बर्बाद करेंगे, या बाद में इसे बस नज़रअंदाज़ करने लगेंगे
      Rust में बहुत ज़्यादा generics और traits होने से code पढ़ना मुश्किल लगने वाला अनुभव याद आता है
  • मैं 90 के दशक में MS की C++ टीम में काम करता था
    तब मुझे लगता था कि RTTI ही reflection system की सीमा है जो C++ कभी पा सकेगा
    आज की प्रगति चौंकाने वाली है

  • Croydon में मीटिंग करके, और साइन होने तक किसी को बाहर न जाने देना, काफ़ी चालाक रणनीति थी
    मैं वहाँ फिर कभी काम नहीं करना चाहूँगा

  • मुझे GCC और Clang की C++26 implementation की स्थिति जाननी थी
    GCC ने तो पहले ही reflection और contracts को trunk में merge कर दिया है, लेकिन Clang कितनी दूर पहुँचा है यह जानना चाहता हूँ

    • Clang status page में दोनों “no” हैं,
      जबकि GCC page में “yes” दिखाया गया है
    • Bloomberg ने Clang के लिए reflection implementation यहाँ सार्वजनिक की है
      यह पहले से Compiler Explorer में इस्तेमाल की जा सकती है, और simdjson में reflection जोड़ने के लिए भी उपयोग हो रही है
  • इस standard में module system के बदलाव क्या वास्तव में इसे ज़्यादा व्यापक उपयोग तक ले जाएँगे, इस पर संदेह है

    • मुझे लगता है C++ WG को कम-से-कम एक बार नए features की जगह modules और packaging पर ध्यान देना चाहिए
      Rust का Cargo जिस वजह से C++ पर भारी पड़ता है, वह यही हिस्सा है
      cargo add की एक लाइन से dependency न जोड़ पाना नई पीढ़ी को दूर करता है
    • ज़्यादातर compilers अभी भी header unit को support नहीं करते
      अगर CMake, Clang के 2-stage compile model को अपनाए, तो build speed में बड़ा सुधार होगा,
      और तभी modules का असली adoption शुरू होगा
    • मुझे लगता है modules पहले से ही एक विफल विचार हैं
      इनके mainstream बनने की संभावना लगभग नहीं है
    • सच कहूँ तो अब C++ development रुक जाना चाहिए
      नए features इतने ज़्यादा हो गए हैं कि साथ बने रहना मुश्किल है
      build systems भी बिखरे हुए हैं, और header files को अब खत्म हो जाना चाहिए
  • विषय से हटकर, “London Croydon” जैसा expression अजीब लगता है
    आम तौर पर “Croydon, London” नहीं कहा जाएगा?

    • “London Gatwick Airport” जैसी सामान्य उल्टी क्रम वाली अभिव्यक्तियाँ भी मौजूद हैं
      यात्रा की योजना बनाते समय बड़े क्षेत्र से छोटे क्षेत्र की ओर पढ़ना अधिक स्वाभाविक लगता है
    • हर व्यक्ति का तरीका अलग होता है कि वह पहले specific बात कहता है या general
      “London, Croydon” लिखने की वजह शायद यह रही होगी कि “लंदन में मीटिंग हुई” वाला impression दिया जाए
      “Croydon, London” से “लंदन के बाहरी हिस्से Croydon में हुई” जैसा एहसास आता है, इसलिए कम आकर्षक लगता है — मज़ाकिया अंदाज़ में की गई व्याख्या
  • कुछ लोगों की निंदक प्रतिक्रिया यह भी है कि “यह भाषा के अप्रासंगिक होने से ठीक पहले आ गया”

  • अगर C++29 सिर्फ quality improvements और मौजूदा features को सँवारने पर ध्यान दे, तो शायद community को ज़्यादा शिकायत नहीं होगी

    • व्यक्तिगत रूप से तो C++29 में सिर्फ एक लाइन का random() function आ जाए, तो भी मैं संतुष्ट रहूँगा
    • बेशक कौन-से features जोड़े जाते हैं, इसके अनुसार community की प्रतिक्रिया बदल सकती है
 
coldmonster91 2026-04-02

C++ standard आने के बाद भी इसे इंडस्ट्री में अपनाने तक 5 साल से ज़्यादा लग जाते हैं, तभी जाकर थोड़ा-थोड़ा adoption शुरू होता है.. आकर्षक तो है, लेकिन बस दूर से अच्छा लगने वाली चीज़ जैसा, sobs

 
woonsa 2026-04-01

मेमोरी सुरक्षा के लिए नए फीचर जोड़ने के बजाय अगर सिर्फ dangling pointers या mutable references को ही रोक दें, तो भी मेमोरी सुरक्षा बढ़ सकती है, लेकिन उल्टा फीचर जोड़ने से सिर्फ कोड की जटिलता ही बढ़ रही है।

 
tsboard 2026-04-01

काफी मेहनत से Rust पर शिफ्ट हुआ था, लेकिन यह उत्साहजनक है कि C++26 के मानक मसौदे में वे कई फीचर्स शामिल कर लिए गए हैं जिनका मैं इंतज़ार कर रहा था। फिर भी मैं दोबारा C++ पर वापस नहीं जाऊँगा... हाहा

 
heal9179 2026-04-01

पैकेजिंग से जुड़ी चीज़ें CMake की तरफ़ से भी आ रही हैं.. https://www.kitware.com/common-package-specification-is-out-the-gate/

 
heal9179 2026-04-01

contract वह फीचर था जिसका मैं सच में इंतज़ार कर रहा था, आखिरकार आ ही गया