Chromium'da yasaklanan C++ özellikleri

• Chromium projesi, kod tutarlılığı ve güvenliğini korumak için modern C++ standart özelliklerinin kullanım kapsamını ve yasaklı öğeleri açıkça tanımlar
• C++11~C++23 arasındaki her standart için izinli, yasaklı ve incelemede (TBD) durumları ayrılır; Abseil kütüphanesi de aynı ölçütlere tabidir
• Yasaklanan özellikler arasında std::shared_ptr, std::function, std::regex, std::filesystem, std::byte, char8_t, modules bulunur
• İzin verilen özellikler arasında concepts, spaceship operatörü, designated initializer, std::to_underlying, std::ranges algoritmaları yer alır
• Bu kılavuz Chromium ve tüm alt projelere uygulanır; kod kararlılığı ve derleme uyumluluğunu sağlamak için temel bir ölçüt olarak çalışır

---

Chromium'un Modern C++ kullanım politikası

• Chromium, modern C++ standartlarını hemen benimsemek yerine, toolchain desteği yeterince sağlandıktan sonra bunları “ilk desteklenen (initially supported)” durumuna alır
  • Ardından özellikler bazında izinli (allowed), yasaklı (banned) ve incelemede (TBD) olarak sınıflandırılır
• Yeni özelliklerin durum değişikliği [e-mail] posta listesi üzerinden önerilebilir
• İlk destekten 2 yıl sonra, açık bir değerlendirme sürecinin ardından ilgili özellik izinli ya da yasaklı listesine taşınır

C++11'de yasaklanan özellikler

• Dil özellikleri: inline namespace, long long, kullanıcı tanımlı sabitler (user-defined literals)
• Kütüphane özellikleri: <chrono>, <regex>, <random> motorları, <exception>, <ratio>, <thread> vb.
  • İstisnalar (exception) tamamen devre dışıdır; yalnızca noexcept kullanımı serbesttir
  • std::bind, std::function, std::shared_ptr, std::weak_ptr yerine base::Bind, base::Callback, base::RefCounted kullanılır

C++17'de yasaklanan özellikler

• UTF-8 karakter sabiti (u8) yasaktır; nedeni char8_t ile uyumluluk sorunlarıdır
• Yasaklı kütüphane öğeleri:
  • matematiksel özel fonksiyonlar, paralel algoritmalar (parallel algorithms), std::any, std::byte, std::filesystem, std::pmr bellek kaynakları vb.
  • Paralel algoritmalar, libc++ desteğinin olmaması ve Chrome'un thread modeliyle çakışma riski nedeniyle yasaktır

C++20'de izin verilen ve yasaklanan özellikler

• İzin verilen dil özellikleri:
  • concepts, consteval, designated initializers, spaceship operatörü, [[likely]], range-for başlatma sözdizimi
• İzin verilen kütüphane özellikleri:
  • <bit>, <compare>, <concepts>, <numbers>, std::erase_if, std::ranges::subrange, std::to_underlying vb.
• Yasaklanan özellikler:
  • char8_t, modules, [[no_unique_address]], std::bit_cast, <span>, std::bind_front, std::ranges::view_interface
• İncelemede (TBD): coroutine, <format>, <source_location>, std::u8string

C++23'te izin verilen ve incelenen özellikler

• İzin verilen dil özellikleri: #elifdef, if consteval, static operator
• İzin verilen kütüphane özellikleri: std::byteswap, std::basic_string::contains, std::to_underlying, genişletilmiş std::ranges algoritmaları
• İncelemede olan özellikler: std::expected, std::mdspan, std::generator, std::stacktrace, std::print, [[assume]], #warning vb.

Abseil kütüphanesi politikası

• Yasaklanan Abseil bileşenleri:
  • absl::any, absl::optional, absl::StatusOr, absl::Span, absl::FunctionRef, absl::Mutex, absl::Time, absl::btree_* vb.
  • Bunların çoğu Chromium'un base namespace uygulamalarıyla değiştirilir (base::span, base::expected, base::Bind vb.)
• İncelemede (TBD): absl::linked_hash_set, absl::linked_hash_map

Genel anlamı

• Chromium, standart C++ özelliklerini koşulsuz kabul etmez; derleme kararlılığı, güvenlik, performans ve kod tutarlılığı ölçütlerine göre seçerek uygular
• Yasaklanan özelliklerin büyük bölümü, yinelenen uygulamalar (base::) veya toolchain/ABI uyumluluğu sorunları nedeniyle dışarıda bırakılmıştır
• Bu kılavuz, Chromium ekosisteminde C++ kod kalitesi yönetimi için temel bir referans olup açık kaynak iş birliğinde mutlaka bakılması gereken bir belge işlevi görür

[karikera]

C++'ın geriye dönük uyumluluk uğruna dilin giderek şişmeye devam etmesi üzücü..

[tsboard]

Gerçekten de HN yorumundaki gibi devasa bir dil C++ ...

[GN⁺]

Hacker News yorumları

• Özellikle göze çarpan bir şey yok ama çoğu, “bizim kullanımımıza uygun kurum içinde geliştirilmiş kütüphaneleri kullanalım” yaklaşımında
  Geri kalanı da locale sorunlarından kaçınmak gibi makul noktalar. Standart kütüphanenin pürüzlü taraflarını düzelten seçenekler de var, bu yüzden anlaşılır geliyor

  • Eski bir kod tabanına sahip şirketlerde buna sık rastlıyorum. Eskiden chrono yoktu, bu yüzden kendi zaman tiplerini yaptılar; STL istikrara kavuşmadan önce de kendi container'larını kullanıyorlardı
    Bugün yeni bir proje başlatsanız bu kuralların çoğunun anlamı kalmaz gibi görünüyor
  • char8_t'nin yasaklanma gerekçesi ilginç. UTF-8 dışındaki encoding'ler neredeyse yok ve char8_t*, char* ile uyumlu değil; bu yüzden her yere saçılan cast'leri önlemek için std::string ya da std::string_view kullanılması öneriliyor
  • 10 yıldan uzun süre bu sayfayı yöneten biri olarak, bu belgenin aynı gün hem r/c++'ta hem HN'de paylaşılmış olması ilginç geliyor. Özel olarak yeni bir şey yokken neden bu kadar gündem olduğunu merak ediyorum
  • Bazı kısımlar sadece ataletten kaynaklanmıyor; Google'ın implementasyonu standarttan daha sıkı ve daha iyi bir tasarıma sahip olduğu için böyle. Standart tipler daha iyi tasarlanmış olabilirdi
  • Google içinde neredeyse her teknolojinin kurum içi bir sürümünün olduğu yönünde bir algı var. Sorun, bazılarının bunu körü körüne taklit edip bağlamı kaybetmesi. 20 geliştiricili ve 50 servisi olan bir organizasyonun Kubernetes benimsemesi bunun tipik örneği

• Eski kod konusu açılınca Chromium'un ilk çıktığı zamanları hatırladım
  Bu kod tabanının tam 20 yıl önce başlatılmış olması şimdi düşününce gerçekten şaşırtıcı

• <regex>'in yasaklanması iyi karar. UTF-8'i düzgün işleyemediği için kullanılamıyordu. Böyle kusurlu bir tasarımın standartlaştırılmış olması şaşırtıcı

  • Bugün çoğu regex kütüphanesi Unicode modu destekliyor. Regex, UTF-8'den daha eski bir teknoloji zaten

• Üst dizinde daha ilginç belgeler var
  Chromium C++ stil kılavuzu bakmaya değer

• Exception'lar yasak ama Windows için istisna var

  • Google kodu başlangıçta C tarzı temelli olduğu için exception-safe değil. Sıfırdan başlansa exception kullanmak daha iyi olurdu ama mevcut kodla uyumluluk yüzünden zor olduğu anlatılıyor
    Yani exception'lar felsefi olarak reddedilmemiş; pratik nedenlerle yasaklanmış. Baştan başlasalardı farklı yapacaklarını söylüyorlar
  • Bu belge Google Style Guide değil, Chromium Modern C++ Features belgesi. Exception veya platforma özgü konuları ele almıyor
  • “exception” ve “Windows” için grep yaptım; sadece [[no_unique_address]] ile ilgili bir ifade çıktı, sanırım şakayı kaçırmışım

• Yasaklı özellik listesi o kadar uzun ki C'nin tüm özelliklerinden bile fazla gibi görünüyor. Bunaltıcı

  • C++ gerçekten devasa bir dil

• u8"..." literal'inin yasaklanması iyi bir tercih. Kaynağın kendisini UTF-8 yazarsanız ayrıca önek gerekmez
  Bu tür literal'ler sorundan önce çözüm üretilmiş bir durum gibi

• Yasaklı özellikler için hangi alternatiflerin önerildiğini görmek istiyorum. Örneğin <filesystem> için test desteğinin yetersiz ve güvenlik açıklarının olduğu söyleniyor

  • Yasakların çoğunda hemen yanında alternatif kütüphane belirtilmiş. <filesystem> bunun istisnası
  • Muhtemelen Chromium geliştirici belgelerinde bununla ilgili bilgi vardır
  • Genelde base/files kullanılıyor

• Modules yasak. Keşke onun yerine D dilinin modül sistemi kopyalansaydı

  • Bunun nedeni yetersiz derleyici desteği

• Yasak listesi, “en yeni özelliklerden çok bağlamın daha önemli olduğunu” gösteriyor. Küçük uygulamalarda sorun olmayabilir ama büyük projelerde riskli

  • Google'ın yönergelerindeki asıl amaç, dil uzmanı olmayanların da güvenle katkı yapabilmesi. Yani mesele proje ölçeğinden çok kurumsal tutarlılık
    Farklı platformlar arasında taşınabilirlik de gözetiliyor
  • Tarihsel nedenler ya da uyumluluk yüzünden kurum içi implementasyonların korunması gereken durumlar da var. Bunlar standardizasyondan önce var olan özellikler olduğu için değiştirmesi zor
  • Ben de yeni özellikleri oraya buraya karıştırmak yerine mevcut kurallara uyarak tutarlılığı korumanın okuyan kişi açısından daha az yük getirdiğini düşünüyorum