D hakkında fazla bir şey bilmiyorum, ama pek çok, birçok C ++ programcısı bundan çok hoşlanmadığımı biliyorum ve şahsen kabul etmek zorundayım - D'nin görünüşünü sevmiyorum ve daha yakından yaklaşmayacağım.
D'nin neden daha fazla çekiş kazanmadığını anlamak için, insanları C ++ 'a çeken şeyi anlayarak başlamanız gerekir. Bir kelimeyle, bir numaralı sebep kontrol. C ++ 'da programladığınızda, programınız üzerinde tam kontrol sahibi olursunuz. Standart kütüphaneyi değiştirmek ister misiniz? Yapabilirsin. Güvenli olmayan işaretçi atmalarını yapmak ister misiniz? Yapabilirsin. Const doğruluğunu ihlal etmek ister misiniz? Yapabilirsin. Bellek ayırıcısını değiştirmek ister misiniz? Yapabilirsin. Ham belleğin türüne bakmadan kopyalamak ister misiniz? Eğer gerçekten istiyorsan. Birden fazla uygulamadan miras almak mı istiyorsunuz? Bu senin cenazen. Kahretsin, Boehm koleksiyoncusu gibi çöp toplama kütüphanelerini bile alabilirsin. O zaman, performansı yakından takip eden, problemleri kontrol eden bir problem var - bir programcının kontrolü ne kadar fazla kontrol ederse, programı o kadar optimize eder.
İşte küçük bir araştırma yaparken ve bunu deneyen birkaç kişiyle konuşurken gördüğüm birkaç şey:
Birleştirilmiş tip hiyerarşi. C ++ kullanıcıları kalıtımı çok nadir kullanır, çoğu C ++ programcısı kompozisyonu tercih eder ve bunu yapmak için çok iyi bir neden varsa, türler yalnızca kalıtım yoluyla bağlanmalıdır. Nesne kavramı, her türü birbirine bağlayarak bu prensibi şiddetle ihlal ediyor. Ayrıca, C ++ 'nın en temel ilkelerinden birini ihlal ediyor - sadece istediğinizi kullanıyorsunuz. Object'ten miras alma konusunda bir seçenek verilmemesi ve bununla birlikte gelen maliyetler, C ++ 'nın programcıya programı üzerinde kontrolü sağlaması açısından bir dil olarak ifade ettiği şeye karşı çok güçlüdür.
Fonksiyon ve delegelerin problemlerini duydum. Görünüşe göre, D hem işlevlere sahiptir ve çalışma zamanı çağrılabilir işlev türleri olarak delege ve aynı değiller ama değiştirilebilir vardır ya ... öyle bir şey? Arkadaşım onlarla epeyce problem yaşadı. Bu kesinlikle C ++ 'dan düşük olan std::functionve sadece sizin yaptığınız gibi.
O zaman uyumluluğun var. D, özellikle C ++ ile uyumlu değildir. Demek istediğim, hiçbir dil C ++ ile uyumlu değildir, bununla yüzleşelim, hile yapan C ++ / CLI hariç, ancak giriş engelleri olarak belirtilmelidir.
O zaman başka şeyler de var. Örneğin, Wikipedia girişini okuyun.
import std.metastrings;
pragma(msg, Format!("7! = %s", fact_7));
pragma(msg, Format!("9! = %s", fact_9));
printfgetsEski C Standart kütüphanesindeki gibi büyük problemlerle aynı ailede, şimdiye kadar tasarlanan en güvenli olmayan fonksiyonlardan biridir . Yığın Taşması ile ilgili arama yaparsanız, yanlış kullanımıyla ilgili birçok soru bulacaksınız. Temel olarak, printfbir DRY ihlalidir- biçim dizesindeki yazıyı veriyorsunuz ve sonra bir argüman verdiğinizde tekrar veriyorsunuz. Eğer yanlış yaparsanız bir DRY ihlali, o zaman çok kötü şeyler oluyor, eğer bir typedef'i bir 16-bit tamsayıdan 32-bit'e değiştirdiyseniz. Ayrıca herkes kendi format belirleyicilerini icat ederse ne olacağını hayal bile edemez. C ++ 'ın akışları yavaş olabilir ve operatör tercihleri en yüksek olmayabilir ve ara yüzleri işi kullanabilir, ancak temel olarak güvenli oldukları garanti edilir ve DRY ihlal edilmez ve kolayca genişletilebilir. Bu söylenebilecek bir şey değil printf.
Çoklu miras yok. Bu çok var değil C ++ yol. C ++ programcıları programları üzerinde tam bir kontrol sahibi olmayı ve miras alamayacağınızı zorlayan dili bu ilkenin ihlali anlamına gelir. Buna ek olarak, kalıtımsallığı (daha da fazla) kırılganlaştırır, çünkü bir türden bir arabirimden bir sınıfa değiştirirseniz, çünkü varsayılan bir uygulama veya bir şey sağlamak istediğinizde, aniden tüm kullanıcı kodunuz bozulur. Bu iyi bir şey değil.
Başka bir örnek stringve wstring. C ++ 'da aralarında dönüşüm yapmak zaten çok acı verici ve bu kütüphane Unicode'u destekliyor mu ve bu eski C kütüphanesi sadece kullanıyor const char*ve istediğiniz dizge argüman türüne bağlı olarak aynı işlevin farklı sürümlerini yazmak zorunda kalıyor . Özellikle, Windows başlıkları, genellikle kendi kodunuzu etkileyebilecek sorunla başa çıkmak için aşırı derecede tahriş edici makrolara sahiptir. dstringKarışıma eklemek , işleri daha da kötüleştirecek, iki dize türü yerine şimdi üçünü yönetmeniz gerekiyor. Birden fazla string tipine sahip olmak bakım ağrılarını artıracak ve stringlerle ilgili tekrarlayan kodlar ortaya çıkaracaktır.
Scott Meyers şöyle yazıyor:
D, programcıların modern yazılım geliştirmenin zorluklarını aşmasına yardımcı olmak için oluşturulmuş bir programlama dilidir. Bunu, hassas arayüzler, birbirine sıkı sıkıya entegre programlama paradigmaları federasyonu, dilin uyguladığı iplik yalıtımı, modüler tip güvenliği, verimli bir bellek modeli ve daha fazlasıyla birbirine bağlanan modülleri teşvik ederek yapar.
Dil tarafından zorlanan iplik yalıtımı bir artı değildir. C ++ programcıları programları üzerinde tam kontrol beklerler ve bir şeyi zorlayan dil doktorun emrettiği gibi değildir.
Ayrıca derleme zamanı string manipülasyonundan da bahsedeceğim. D derleme zamanında D kodunu yorumlama yeteneğine sahiptir. Bu bir artı değil. C'nin tüm deneyimli C ++ programcıları tarafından iyi bilinen, nispeten sınırlı önişlemcisinin neden olduğu büyük baş ağrıları düşünün ve ardından bu özelliğin ne kadar kötüye kullanılacağını hayal edin. Derleme zamanında D kodu oluşturma yeteneği harikadır, ancak sözdizimsel değil, anlamsal olması gerekir .
Ayrıca, belirli bir refleks bekleyebilirsiniz. D, C ++ programcılarının felsefelerde doğrudan karşıt olan Java ve C # gibi dillerle ilişkilendirecekleri çöp koleksiyonuna sahiptir ve sözdizimsel benzerlikleri de bunları akla getirecektir. Bu mutlaka nesnel olarak haklı değildir, ancak kesinlikle belirtilmesi gereken bir şeydir.
Temel olarak, C ++ programcılarının yapamayacağı kadar fazla bir şey sunmuyor. Belki D'de bir faktöryel metaprogram yazmak daha kolay, ama biz olabilir C ++ faktöryel metaprograms zaten yazın. Belki D'de sen yapabilirsiniz derleme zamanı ışın-izleyici yazmak, ama kimse gerçekten Zaten bunu yapmak istiyor. C ++ felsefesinin temel ihlalleriyle karşılaştırıldığında, D'de yapabilecekleriniz özellikle dikkate değer değildir.
Bu şeyler sadece yüzeyde sorun olsa bile, o zaman yüzeydeki D'nin aslında C ++ 'ya hiç bakmadığı gerçeğinden eminim, pek çok C ++ programcının D'ye geçmemesi için iyi bir sebep. Belki de D, kendisini daha iyi tanıtan bir iş ilanına ihtiyaç duyar.