गेम डेवलपर्स के लिए C++20 की शरारती और अच्छी सूची

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

C++20 की नई विशेषताएँ game developers के बीच मिली-जुली प्रतिक्रियाएँ पैदा कर रही हैं: वे तीन-तरफ़ा comparison operator, `std::bit_cast`, और coroutines जैसी सुविधाओं का स्वागत करते हैं, लेकिन compile times, code bloat, और tooling gaps को लेकर चिंतित हैं। String formatting के लिए `{fmt}`/`std::format` और designated initializers safer, अधिक expressive APIs तथा भारी templates या कड़े initialization rules के बीच trade-off दिखाते हैं, जो 10M+ line AAA codebases में बहुत मायने रखता है। कुछ developers Rust-like patterns की ओर refactor कर रहे हैं या पूर्ण Rust rewrites पर विचार कर रहे हैं, यह तर्क देते हुए कि safety और ergonomics, C++ के undefined behaviors और low-level optimization leeway से जुड़े मामूली performance wins से अधिक मूल्यवान हो सकते हैं।

तीन-तरफ़ा तुलना ऑपरेटर <=>

  • कई टिप्पणियाँ बताती हैं कि किसी type के लिए <=> परिभाषित करने से अपने-आप सभी छह comparison operators (<, >, <=, >=, ==, !=) बन जाते हैं, जिससे boilerplate कम हो जाता है।
  • यह समान objects के लिए implementation को सरल बनाता है क्योंकि केवल एक routine को “plumbed” करना पड़ता है।

std::format / {fmt}: performance, bloat, और compile times

  • कुछ लोग fmt/format.h की आलोचना देखकर हैरान हैं; अन्य सहमत हैं कि heavy templates और header-only style बड़े C++20 codebases में compile times को नुकसान पहुँचाते हैं।
  • एक पक्ष का तर्क है कि code-size bloat को आधुनिक linkers और भारी logic को .cc files में ले जाने से काफी हद तक कम किया जा सकता है; बड़ा concern compile-time है।
  • {fmt} के समर्थक कहते हैं कि यह build speed के लिए optimized है, iostreams से बेहतर प्रदर्शन कर सकता है, और performance-critical numeric formatting तथा I/O में व्यापक रूप से इस्तेमाल होता है।
  • इस बात को लेकर भ्रम है कि सुझाए गए “dispatch to non-template TU” pattern को <format> के साथ भी क्यों नहीं इस्तेमाल किया जा सकता था।

बड़े game codebases में C++20 features

  • चर्चा इस पर केंद्रित है कि AAA engines के लिए 10M+ LOC वास्तविक है (Unreal जैसे उदाहरणों के साथ), और incremental builds तथा खासकर link times कितने दर्दनाक हैं।
  • Distributed builds और Incredibuild जैसे tools मदद करते हैं, लेकिन linkers (विशेष रूप से MSVC के) अभी भी bottleneck बने रहते हैं।
  • कुछ लोग पूछते हैं कि कोई अक्सर कुछ फ़ाइलों से अधिक recompile क्यों करेगा; अन्य बताते हैं कि core headers या compiler flags में बदलाव बड़े rebuilds को ट्रिगर करते हैं।

Designated initializers और C बनाम C++ semantics

  • बहुतों को यह पसंद नहीं कि C++ में designated initializers को declaration order का पालन करना पड़ता है, जबकि C में ऐसा नहीं है।
  • इसके औचित्य में शामिल हैं:
    • C++ में member initialization और destruction order महत्वपूर्ण होते हैं।
    • Members पहले वाले members की initialization पर निर्भर हो सकते हैं (उदा., int b = a + 1)।
    • मनमाने order की अनुमति देने से सूक्ष्म bugs पैदा हो सकते हैं या मौजूदा नियम तोड़ने पड़ सकते हैं।
  • कुछ लोग तर्क देते हैं कि “C-like” POD structs के लिए नियम ढीले किए जा सकते हैं, लेकिन अन्य कहते हैं कि structs बदलने पर यह नाज़ुक हो जाएगा।
  • कई लोग C++ के restricted designated init को फिर भी उपयोगी मानते हैं, भले ही वह C99 के मुकाबले कम शक्तिशाली हो (nested chains नहीं, array index designators नहीं)।

Game engines और dynamic loading के लिए Rust बनाम C++

  • एक developer C++ game engine को Rust में rewrite करने के लिए ललचाता है क्योंकि ergonomics बेहतर हैं, लेकिन schedule impact से डरता है, इसलिए C++ को “Rust-ready” बना रहा है (ownership, data-oriented design)।
  • Rust और dynamic libraries को लेकर बहस है:
    • कुछ लोग दावा करते हैं कि Rust सामान्य रूप से dynamic libraries “allow” नहीं करता; अन्य बताते हैं कि dylib मौजूद है, लेकिन interoperability के लिए अक्सर C ABIs की ज़रूरत होती है।
    • DLL hot-reload जैसे game workflows, “normal C++” के साथ, एक बड़ा लाभ बताए जाते हैं; व्यवहार में, stable plugin boundaries के लिए C++ और Rust दोनों अक्सर C ABIs पर ही लौटते हैं।
    • separate processes और IPC के माध्यम से एक alternative plugin model पर चर्चा होती है, लेकिन इसे in-process calls की तुलना में orders of magnitude धीमा माना जाता है।

Signed overflow UB और optimization

  • एक commenter का तर्क है कि signed overflow को undefined रखने से performance लाभ छोटा है (जैसे, कभी-कभी sign-extension instruction से बचना), और यह केवल विशिष्ट loop patterns को प्रभावित करता है।
  • अन्य लोग clarification माँगते हैं; explanations इस पर केंद्रित हैं कि compilers no-overflow assumption के तहत loop indices और array indexing के बारे में कैसे reason करते हैं।
  • या तो signed overflow को wrap करने (-fwrapv जैसा) या overflow traps की गारंटी देने के लिए समर्थन है; current UB को छोटे speed gain के बदले खराब trade-off माना जाता है।

std::bit_cast, unions, और constant evaluation

  • कुछ लोग std::bit_cast मिलने से राहत महसूस करते हैं ताकि union-based type punning को बदला जा सके, जो C++ में UB है, भले ही compilers व्यवहार में इसे सामान्यतः “accept” कर लेते हैं।
  • यह reviewers को सुरक्षित patterns अपनाने के लिए प्रेरित करने में मदद करता है, खासकर C से आने वाले students के लिए।
  • std::is_constant_evaluated() का उल्लेख होता है लेकिन वास्तव में उस पर विस्तार नहीं किया जाता; heavy numeric/physics workloads के लिए इसके लाभ thread में स्पष्ट नहीं हैं।

Coroutines और tooling / debuggability

  • कुछ लोगों के लिए coroutines “nice” सूची में हैं: वे callbacks से तेज़ और अधिक type-safe हो सकते हैं, और अक्सर async control flow को पढ़ना आसान बनाते हैं।
  • एक बड़ा pain point debugging है: coroutine crashes के stack traces में अक्सर सिर्फ framework/boilerplate frames दिखते हैं, user code नहीं।
  • कुछ लोग नोट करते हैं कि callback-heavy code को debug करना भी painful है, और tooling gaps के बावजूद वे coroutines को प्राथमिकता देते हैं।

Ranges, lambdas, और “non-linearizing” control flow

  • एक दृष्टिकोण यह है कि ranges और inline lambdas का भारी उपयोग code को follow करना कठिन बना देता है:
    • lambdas के बाहर का code पहले चलता है, जबकि lambda bodies बाद में, कई बार, या कभी भी नहीं चल सकतीं।
    • reference/value द्वारा captures, यदि सावधानी से reason न किया जाए, तो subtle lifetime और mutation bugs ला सकते हैं।
  • अन्य लोग इसे स्वीकार करते हैं, लेकिन फिर भी deeply nested callbacks की तुलना में coroutines और higher-level abstractions को उपयोगी मानते हैं।