C dilinin yapması gereken bariz şeyler

• C’deki bariz iyileştirmeler

  • C23 standardı: C dili düzenli olarak geliştiriliyor ve şu anda C23’e ulaştı. Ancak hâlâ çözülmemiş sorunlar var.
  • Dlang topluluğunun çabası: D programlama dili derleyicisine bir C derleyicisi olan ImportC’yi gömerek bu sorunları çözmek için bir fırsat sunuyor.

• Sabit ifade değerlendirmesi

  • Sorun: C, derleme zamanında basit ifadeleri hesaplayabiliyor ancak fonksiyon çalıştırmak mümkün değil.
  • ImportC’nin çözümü: ImportC, derleme zamanında fonksiyon çalıştırılmasına izin vererek bu sınırlamayı aşıyor.

• Derleme zamanı birim testleri

  • C’deki sorun: C kodunda birim testleri ayrı bir build hedefi gerektirdiği için zahmetli.
  • ImportC’nin avantajı: ImportC, derleme zamanında fonksiyon değerlendirmesi sayesinde birim testlerinin kolayca çalıştırılmasını sağlıyor.

• Bildirimlerin ileri referansı

  • C’nin kısıtı: C, bildirimlerin sırasına duyarlıdır ve ileri referansa izin vermez.
  • ImportC’nin avantajı: ImportC, bildirim sırasına bağlı değildir ve global bildirimlere herhangi bir sırayla izin verir.

• Bildirim içe aktarma

  • Mevcut yöntemin sorunu: Her harici modül için .h dosyası yazma zahmeti vardır.
  • ImportC’nin çözümü: ImportC, .h dosyaları olmadan da bildirimleri içe aktarabildiği için verimlidir.

• Referans materyalleri

  • ImportC belgeleri: ImportC hakkında ayrıntılı bilgi sunar.
  • D dili belgeleri: D dili hakkında ek bilgi sunar.

[GN⁺]

Hacker News görüşleri

• C dilinde header dosyaları kamusal ve kamusal olmayan kısımları, arayüz ile implementasyonu net biçimde ayırabildiği için iyi. .h dosyaları sayesinde bir kütüphanenin nasıl kullanılacağını kolayca anlamak mümkün

  • Dokümantasyon .h dosyalarında yoğunlaştığı için .c dosyalarından farklı görünüyor
  • Dokümantasyon .c dosyalarına da konabilir, ancak bu arayüzü okumayı zorlaştırır

• C dilinde fonksiyonların derleme zamanında çalıştırılabilmesi gerektiği yönünde bir görüş var, ancak çalışma süresi uzun olan fonksiyonlar sorun yaratabilir

  • Örnek olarak busybeaver fonksiyonu veriliyor

• Sabit ifade değerlendirmesi, derleme zamanı unit testleri, bildirimlerin ileri referansı ve bildirim içe aktarma gibi sorunlara nasıl çözüm bulunacağı merak ediliyor

  • Sabit ifade değerlendirmesi: çeviri birimi içinde yapılırsa basit, ancak kod tekrarını gerektiriyor
  • Derleme zamanı unit testleri: makrolarla ifade edilebilir, ancak ilk nokta eklenirse daha kolay olur
  • Bildirimlerin ileri referansı: derleyicinin iki geçiş yapmasını gerektirebilir ve performansı etkileyebilir
  • Bildirim içe aktarma: C'de template uygulama yöntemlerini bozabilir

• C kodu için unit test yazmak, iyi bir build sistemi ve biraz boilerplate ile mümkün

  • Örnek olarak npy kütüphanesinin test kodu veriliyor

• Sabit ifade değerlendirmesi karmaşıklaştığında derleyici hızı düşebilir ve bir VM gerekebilir

  • C++20'deki tanımdan ziyade modülleri sembol olarak içe aktarma yönünün daha iyi olacağı görüşü var

• Derleme zamanı unit testleri geliştiricinin kontrolünü elinden alır ve işi tamamlamak için gereksiz prosedürler dayatır

  • Build failure testleri nihai build için iyi olsa da ara build'ler için uygun değil

• Fonksiyon tanımlarını "yukarıdan aşağıya" yapmanın daha iyi olup olmadığı tartışılıyor

  • Python gibi dillerde de yukarıdan aşağıya tanımlama yaygındır
  • Yukarıdan aşağıya tanımlamanın belirli kod türlerine daha uygun olup olmadığı soruluyor

• C diline eklenmesi istenen özellikler

  • Pointer ve uzunluğu kodlayan slice tipi desteği
  • Reentrant ve thread-safe API'ler
  • Go ve Zig'deki defer benzeri bir özelliğin standartlaştırılması
  • Unicode ve UTF-8 için taşınabilir destek

• C'nin basit implementasyonu bir avantaj ve kapsamını büyük ölçüde genişletmek iyi bir fikir değil

  • Scheme'de olduğu gibi "küçük" ve "büyük" sürüm spesifikasyonları olabilir

• Fonksiyon tanımlarını yukarıdan aşağıya yapmanın daha iyi olmasının nedenleri

  • Fonksiyon içinde kod yazma biçimine benzemesi
  • Modül içinde fonksiyonların konumunun açık olması
  • Döngüsel bağımlılıkların net biçimde görülebilmesi
  • Döngüsel bağımlılıklar kod tabanını karmaşıklaştırır ve modülü anlamayı zorlaştırır
  • OCaml fonksiyonlar arasında döngüsel bağımlılıklara izin vermez