Sorunun dil etiketi olmasa da, muhtemelen “kahve dilleri” nden dolaylı olarak bahsettiğinin farkındayım. Ama sadece bütünlük uğruna, C ++ dünyasında biraz farklı görünen fikir birliğinden bahsetmek istiyorum.
C ++ programcılarının ilgilendiği üç şey vardır:
- Optimize edilmiş yapılarda sıfır ek yükü olacak mı? (Yani, “derlenebilir”?)
- Hatanın tespit edildiği noktada bir hata ayıklayıcıya sıkışmak için kullanabilir miyim?
- Bildirilen işlevlerden gelen sorunları bildirmek için kullanabilir miyim
noexcept?
Geçmişte, ilk soruna şöyle kod yazarak yaklaştım
int
factorial(const int n)
{
if (CHECK_ARGS)
{
if (n < 0)
throw std::invalid_argument {"n < 0"};
}
int fac = 1;
for (int i = 2; i <= n; ++i)
fac *= i;
return fac;
}
burada CHECK_ARGSbir #definederleyici tamamen tüm bağımsız değişken kontrol kodu ortadan kaldırabilir, böylece bir derleme sabitine d optimize oluşturur. (Çekleri derlemenin genel olarak iyi bir şey olduğunu söylemiyorum ama bir kullanıcının bunları derleme seçeneğine sahip .)
Hala bu çözüm hakkında argüman kontrol kodu açıkça birlikte gruplandırılmış görünür gibi if. Ancak, ikinci ve üçüncü konu bununla çözülmez. Bu nedenle, şimdi tekrar daha çokassert argüman kontrolü için makro .
Standartları kodlama Boost buna katılıyor:
Programcı Hataları Nedir?
Bir geliştirici olarak, kullandığım bir kütüphanenin önkoşulunu ihlal etsem, yığın gevşemesini istemiyorum. Ne istiyorum bir çekirdek dökümü ya da eşdeğer - programın durumunu sorunun tam olarak tespit edildiği noktada incelemek için bir yoldur. Bu genellikle assert()bunun gibi bir şey anlamına gelir .
John Lakos tarafından CppCon'14'te Savunma Programlama Tamamlandı başlıklı çok ilginç bir konuşma yapıldı ( bölüm 1 , bölüm 2) ) . Konuşmasının ilk bölümünde sözleşme teorisi ve tanımlanmamış davranış tartışıyor. İkinci bölümde, sistematik argüman kontrolü için çok iyi bir teklif olarak gördüğümü sunar. Özünde, kullanıcının bir bütçenin ne kadarını (CPU kullanımı açısından) argüman kontrolü için kütüphaneye bağışlamak istediğini seçmesine izin veren iddia makroları önermekte ve kütüphanenin bu bütçeyi akıllıca kullanmasını sağlamıştır. Buna ek olarak, kullanıcı, kırık bir sözleşme tespit edilmesi durumunda çağrılacak olan genel bir hata işleme fonksiyonu da kurabilir.
Bir fonksiyonun özel olduğu yönüyle ilgili olarak, bunun argümanlarını asla kontrol etmememiz gerektiği anlamına gelmez . Dahili bir fonksiyonun sözleşmesini ihlal etmemek için kendi kodumuza daha fazla güvenebiliriz, ancak aynı zamanda mükemmel olmadığımızı da biliyoruz. Dahili işlevlerde bağımsız değişken denetimi, kendi hatalarımızı algılamak için, istemci kodundaki hataları algılamak için genel işlevlerde olduğu gibi yardımcı olur.