Chromium में प्रतिबंधित C++ फीचर्स

• Chromium प्रोजेक्ट आधुनिक C++ standard features के उपयोग-क्षेत्र और प्रतिबंधित आइटम्स को स्पष्ट रूप से परिभाषित करता है, ताकि code consistency और security बनी रहे
• C++11~C++23 तक हर standard के लिए allowed, banned और under review (TBD) स्थिति अलग-अलग तय की गई है, और Abseil library पर भी यही मानदंड लागू होते हैं
• प्रतिबंधित फीचर्स में std::shared_ptr, std::function, std::regex, std::filesystem, std::byte, char8_t, modules आदि शामिल हैं
• अनुमत फीचर्स में concepts, spaceship operator, designated initializer, std::to_underlying, std::ranges algorithms आदि शामिल हैं
• यह guide Chromium और उसके सभी sub-projects पर लागू होती है, और code stability व build compatibility सुनिश्चित करने के लिए एक मुख्य मानदंड की तरह काम करती है

---

Chromium की Modern C++ उपयोग नीति

• Chromium नए C++ standard को तुरंत adopt नहीं करता, बल्कि toolchain support पर्याप्त रूप से सुनिश्चित होने के बाद उसे ‘initially supported’ स्थिति देता है
  • इसके बाद हर feature को allowed, banned, या under review (TBD) में वर्गीकृत किया जाता है
• नए features की स्थिति बदलने का प्रस्ताव [e-mail] mailing list के जरिए दिया जा सकता है
• initial support के 2 साल बाद, स्पष्ट review के जरिए feature को allowed या banned सूची में ले जाया जाता है

C++11 के प्रतिबंधित फीचर्स

• language features: inline namespace, long long, user-defined literals
• library features: , , engine,, , आदि
  • exception पूरी तरह disabled हैं, और केवल noexcept की अनुमति है
  • std::bind, std::function, std::shared_ptr, std::weak_ptr की जगह base::Bind, base::Callback, base::RefCounted का उपयोग किया जाता है

C++17 के प्रतिबंधित फीचर्स

• UTF-8 character literal (u8) प्रतिबंधित है, क्योंकि char8_t के साथ compatibility समस्या है
• library में प्रतिबंधित आइटम्स:
  • special math functions, parallel algorithms, std::any, std::byte, std::filesystem, std::pmr memory resources आदि
  • parallel algorithms पर libc++ support नहीं है और Chrome के threading model से टकराव की आशंका के कारण इन्हें प्रतिबंधित किया गया है

C++20 के अनुमत और प्रतिबंधित फीचर्स

• अनुमत language features:
  • concepts, consteval, designated initializers, spaceship operator, [[likely]], range-for initialization syntax
• अनुमत library features:
  • , , , , std::erase_if, std::ranges::subrange, std::to_underlying आदि
• प्रतिबंधित फीचर्स:
  • char8_t, modules, [[no_unique_address]], std::bit_cast, ``, std::bind_front, std::ranges::view_interface
• under review (TBD): coroutine, , , std::u8string

C++23 के अनुमत और समीक्षााधीन फीचर्स

• अनुमत language features: #elifdef, if consteval, static operator
• अनुमत library features: std::byteswap, std::basic_string::contains, std::to_underlying, std::ranges expanded algorithms
• समीक्षााधीन फीचर्स: std::expected, std::mdspan, std::generator, std::stacktrace, std::print, [[assume]], #warning आदि

Abseil library नीति

• प्रतिबंधित Abseil components:
  • absl::any, absl::optional, absl::StatusOr, absl::Span, absl::FunctionRef, absl::Mutex, absl::Time, absl::btree_* आदि
  • इनमें से अधिकतर को Chromium के base namespace implementations से replace किया जाता है (base::span, base::expected, base::Bind आदि)
• under review (TBD): absl::linked_hash_set, absl::linked_hash_map

समग्र अर्थ

• Chromium standard C++ features को बिना शर्त स्वीकार नहीं करता, बल्कि build stability, security, performance और code consistency के आधार पर चुनिंदा रूप से अपनाता है
• अधिकांश प्रतिबंधित फीचर्स के पीछे duplicate implementations (base::) या toolchain·ABI compatibility issues कारण हैं
• यह guide Chromium ecosystem के लिए C++ code quality management standard की तरह काम करती है, और open source collaboration में एक जरूरी reference document है

[karikera]

C++ में backward compatibility की वजह से भाषा का लगातार और भारी होती जाना थोड़ा अफ़सोसजनक है..

[tsboard]

वाकई HN की राय में कहा गया है, C++ एक बहुत विशाल भाषा है ...

[GN⁺]

Hacker News की राय

• इसमें खास तौर पर कुछ बहुत अलग नहीं दिखता, ज़्यादातर बातों का मतलब है, “हम अपने उपयोग के हिसाब से बनी इन-हाउस लाइब्रेरी इस्तेमाल करें”
  बाकी हिस्से भी काफ़ी वाजिब हैं, जैसे locale से जुड़ी समस्याओं से बचना। standard library के खुरदरे हिस्सों को smooth करने वाले विकल्प भी हैं, इसलिए बात समझ में आती है

  • पुराने codebase वाली कंपनियों में ऐसा अक्सर देखा जाता है। पहले chrono नहीं था, इसलिए उन्होंने अपना time type बनाया, और STL के stable होने से पहले से अपने containers इस्तेमाल करते रहे
    अगर आज कोई नया project शुरू किया जाए, तो शायद इनमें से ज़्यादातर नियमों का कोई मतलब न रहे
  • char8_t को ban करने की वजह दिलचस्प है। UTF-8 के अलावा encoding अब लगभग होती नहीं, और char8_t* का char* से compatibility नहीं है, इसलिए casts की भरमार रोकने के लिए std::string या std::string_view इस्तेमाल करने की सलाह दी गई है
  • जिसने 10 साल से ज़्यादा समय तक इस page को maintain किया हो, उसके नज़रिए से यह दिलचस्प है कि यह दस्तावेज़ उसी दिन r/c++ और HN दोनों पर एक साथ आया। इसमें कोई ख़ास नई बात नहीं है, तो समझ नहीं आता कि यह अचानक चर्चा में क्यों आ गया
  • कुछ चीज़ें सिर्फ inertia की वजह से नहीं हैं, बल्कि इसलिए भी कि Google के implementation में standard से ज़्यादा सख़्त और बेहतर design है। standard types को इससे बेहतर design किया जा सकता था
  • लोगों के बीच यह धारणा है कि Google के अंदर लगभग हर technology का अपना version होता है। दिक्कत तब होती है जब कुछ लोग उसे अंधाधुंध copy करते हैं और context खो देते हैं। 20 developers और 50 services वाली संस्था में Kubernetes लाना इसका अच्छा उदाहरण है

• पुराने code की बात से Chromium के शुरुआती दिनों की याद आ गई
  यह सोचकर फिर हैरानी होती है कि यह codebase 20 साल पहले शुरू हुआ था

• <regex> को ban करना अच्छा फ़ैसला था। यह UTF-8 को ठीक से handle नहीं कर पाता था, इसलिए इस्तेमाल लायक ही नहीं था। ऐसी ख़राब design का standardize हो जाना हैरान करता है

  • आजकल ज़्यादातर regex libraries Unicode mode सपोर्ट करती हैं। regex, UTF-8 से पहले की technology है

• ऊपर वाली directory में और भी दिलचस्प documents हैं
  Chromium C++ Style Guide भी देखने लायक है

• exceptions पर ban है, लेकिन Windows के लिए अपवाद रखा गया है

  • Google का code मूल रूप से C-style base पर बना था, इसलिए वह exception-safe नहीं है। अगर आज से नया शुरू करते तो exceptions इस्तेमाल करना बेहतर होता, लेकिन पुराने code के साथ compatibility की वजह से यह मुश्किल है
    यानी exceptions को किसी दार्शनिक वजह से नहीं, बल्कि व्यावहारिक कारणों से ban किया गया। अगर शुरू से फिर बनाते, तो शायद फ़ैसला अलग होता
  • यह दस्तावेज़ Google Style Guide नहीं बल्कि Chromium Modern C++ Features document है। इसमें exceptions या platform-specific बातों पर चर्चा नहीं है
  • मैंने “exception” और “Windows” grep करके देखा, वहाँ सिर्फ [[no_unique_address]] से जुड़ा ज़िक्र मिला, तो शायद मैं मज़ाक समझ नहीं पाया

• banned features की सूची इतनी लंबी है कि वह C की पूरी feature list से भी बड़ी लगती है। हैरान कर देने वाली

  • C++ सच में बहुत विशाल भाषा है

• u8"..." literal को ban करना अच्छा फ़ैसला है। अगर source खुद UTF-8 में लिखा जाए, तो अलग prefix की ज़रूरत नहीं पड़ती
  ऐसे literals समस्या से पहले आए समाधान जैसे लगते हैं

• मैं banned features के alternatives ढूँढना चाहता हूँ। उदाहरण के लिए <filesystem> के बारे में कहा गया है कि उसमें testing support कम है और security vulnerabilities हैं

  • ज़्यादातर banned items के ठीक बगल में alternative library लिखी हुई है। सिर्फ <filesystem> इसका अपवाद है
  • शायद Chromium developer docs में इससे जुड़ी जानकारी हो
  • आम तौर पर base/files इस्तेमाल किया जाता है

• modules को ban किया गया है। काश D language के module system को ही copy कर लिया गया होता

  • इसकी वजह compiler support की कमी है

• यह ban list दिखाती है कि “नए features” से ज़्यादा context मायने रखता है। छोटी apps में ये दिक्कतें नहीं होतीं, लेकिन बड़े projects में जोखिम बढ़ जाता है

  • Google की guidelines का मकसद यह है कि language expert न होने पर भी लोग सुरक्षित तरीके से contribute कर सकें। यानी focus project size से ज़्यादा organizational consistency पर है
    अलग-अलग platforms के बीच portability भी ध्यान में रखी गई है
  • कई बार historical reasons या compatibility की वजह से अपनी implementations बनाए रखनी पड़ती हैं। ये features standardization से पहले से मौजूद थे, इसलिए बदलना आसान नहीं है
  • मुझे भी लगता है कि नई features को जगह-जगह मिलाने से बेहतर है मौजूदा rules के हिसाब से consistency बनाए रखना, ताकि पढ़ने वाले पर कम बोझ पड़े