C ++ neden hala “melez”

Bir Açık ilgili C ++ birçok konuda C ile uyumlu değildir neden sorusuna, bu açıklığa kavuşturulmuştur. Ancak C ++ hala bir "karma" * dildir. Ne yazık ki, birçok programcı hala C ++ 'ı "akışlı ve yerleşik dizeli C" olarak görüyor. Bu gerçekten kötü yazılı kodla sonuçlanır, ne C ++ ne de C. IMHO değildir, dil / derleyici bir dereceye kadar programcıları daha zarif kod yazmaya zorlarsa daha iyi olurdu. Modern C ++ (örneğin C ++ 0x ve gelecekteki sürümler) karma tutmak için bir gerekçe var mı?

_{* Hibrit ile, programcının kullanıp kullanamayacağına karar vermenin programa bağlı olduğunu kastediyorum: standart dizeler ve akışlar, sınıflar, varsayılan dışındaki ad alanları vb.}

Evet, güçlü bir gerekçe var: C ++ kodu hemen hemen her zaman mevcut C kodunu çağırmak zorunda. Yapabileceğimiz en iyi şey, iyi kod yazmayı kolaylaştırmaktır. Bir dil tasarımcısının kötü kod yazmayı imkansız hale getirmek için yapabileceği hiçbir şey yoktur.

IMHO, dilin / derleyicinin bir dereceye kadar programcıları daha zarif kod yazmaya zorlaması daha iyi olurdu.

Hayır. Hiç. Nedenin önemsiz bir gösterisi olarak, zarif tanımlayın ve sonra on kişinin sizinle aynı fikirde olmayacağına bahse girerim.

Dil tarafından zorlanan kodlama stilleri gerçekten çok kötü. Kırılacak tüm eski kodlardan bahsetmiyorum bile.

Özellikle, Standart dize ve akış sınıfları aslında emer . std::stringUnicode desteği ve hayal edebileceğiniz en kötü şişkin arayüze sahip değil. Akarsular korkunç bir ek yüke ve kötü bir tasarıma sahip, hatta sanal kalıtım, işlev işaretçileri ve const char*ve bunun gibi çirkinler. Bu sınıfların / sınıf gruplarının her ikisini de özel gruplarla tamamen değiştirdiği için kimseyi cezalandırmam.

Sınıfları ve ad alanlarını kullanmamak beyaz tahta tarzı kod için iyidir ve bir sınıfta olmayan işlevler sağlayan birçok kitaplık vardır. Zorla sınıf gerçekten kötü bir fikir.

C ++, C stili kod yazmasına izin verdiği için değil, yordamsal, nesne yönelimli ve genel gibi çeşitli programlama paradigmalarını desteklediği için bir melezdir. C ++ sizi bir şeyler yapmaya zorlamaz ve bu onun gücüdür, çünkü farklı problemler farklı paradigmalar kullanılarak daha kolay çözülebilir.

IMHO, dilin / derleyicinin bir dereceye kadar programcıları daha zarif kod yazmaya zorlaması daha iyi olurdu.

Sonra ilk olarak ne tanımlamak zorunda zarif demektir. Daha sonra zarif tanımınızın C ++ 'ın kullanıldığı tüm sorun alanları ve platformları için uygun olup olmadığını görmeniz gerekir. Windows için bir kelime işlemci yazmak için zarif olan bir kodlama stili, gömülü bir sistem yazmak için tamamen uygun olmayabilir.

Bir DSP'de çalıştırmak için C ++ kodu yazmayı düşünün. İlk olarak, bu DSP için C ++ derleyicisi akışlar gibi bazı C ++ özelliklerini desteklemeyebilir. İkincisi, CPU hızı ve muhtemelen bellekle ciddi şekilde kısıtlandınız, bu nedenle bazı C ++ özellikleri performansınızı öldürebilir. Örneğin, hız uğruna sanal işlevlerden kaçınmanız gerekebilir. Bu tür düşünceler, bir bilgisayarda ne kullanacağınıza kıyasla programlama stilinizi kökten değiştirir ve C ++ buna izin verir.

Özetle, C ++ birçok özelliğe sahip devasa ve karmaşık bir dildir. Bu özelliklerin herhangi bir alt kümesinin belirli bir proje için geçerli olmamasının birçok nedeni vardır: hız, taşınabilirlik, derleyici desteği, hatta programcı deneyimi ve aşinalık. Bu nedenle, dilin geliştiriciyi herhangi bir görev için başkalarının aksine belirli özellikleri kullanmaya zorlaması kötü bir fikirdir. Dilin her işlevin bir sınıf yöntemi olması gerektiğini zorunlu kıldığı Java'yı düşünün. Sadece bir yöntemi sarmak için bir sınıf oluştururken çok fazla durum vardır ve yine de bunu yapmak zorundasınız çünkü dil sizi zorlar.

IMHO, dilin / derleyicinin bir dereceye kadar programcıları daha zarif kod yazmaya zorlaması daha iyi olurdu.

Hiç kimse kimseyi C ++ kullanmaya zorlamıyor . Dil size uymuyorsa farklı bir dil kullanın - "C olmadan C ++" olarak faturalandırılan birçok dil vardır.

C ++ tasarım felsefesi programcının karar vermesine izin vermektir. Kendilerini ayağa vurmak istiyorlarsa bırakın. Bu, birçok kötü şeyin yapılmasına izin verir, ancak aynı zamanda büyük bir esneklik sağlar. Örneğin, Boost'un Java gibi bir dilde yazılabilmesi olası değildir, çünkü yaygın olarak kullanılan dil özelliklerinden ve uygulamalarından yararlanır. C ++ 'nın bugünkü kadar genişlemesi de olası değildir - geniş C kütüphanesine erişim büyük bir artı, al ya da bırak.

C ++ 'ın C ile uyumluluğu kesinlikle en zayıf noktalarından biridir, ancak bunun en büyüklerinden biri olduğunu unutmayın.

Jon Purdy'nin son derece alakalı olduğunu düşündüğüm harika bir alıntı ekleyeceğim:

Her şey pragmatizme zerafet karşı gelir ve benim için, kesin, güzel kodla saplantıma rağmen, işe yarayan çirkin bir program yazmak, hiçbir şey yapmayan güzel bir program yazmaktan daha iyidir.

Melezin çıkarılması zarafeti artırabilir, ancak yeteneği engeller.

Eğer komite insanları daha zarif bir dil kullanmaya zorlayacaksa, muhtemelen göz ardı edilecektir. İnsanlar istediklerini yapmaya devam edeceklerdi ve derleyici satıcılar piyasayı takip edecekti (ancak derleyici satıcıları bunu önlemek için komitede yeterli temsile sahipler).

Savunacağınız şeylerin çoğu, zaten sorun alanına dayanarak bir yargı meselesidir. Sadece (bir örnek için) isim alanlarına ihtiyaç duymayan çok sayıda küçük program var. 30 satırlık bir metin filtresi yazarken beni bir ad alanı kullanmaya zorlamak aptalca ve kibirli olurdu. Yalnızca X'dan fazla kod satırı veya Y işlevi veya ne dahil olursa olsun uygulanacağına karar verseniz bile, yine de genellikle ters etki yaratacaktır. Ad alanları, belirli sorunları önlemek / iyileştirmek için bir nedenle tasarlanmıştır. Bu sorunların yokluğunda kullanımlarını zorlamaya çalışmak herkes için yararlı bir şey yapmaz.

Aynı zamanda, çok az insanın sadece C ++ 'da zarafeti etkinleştirmek için değil, aynı zamanda daha iyi kod yazmak için bu yetenekleri kullanmalarını öğretmek ve yönlendirmek için çok fazla zaman ve çaba harcadığını belirtmek gerekir. birçok Boost katılımcısı). Bu nedenle, kodlarını "sınıflarla C" olarak yazmakta ısrar eden insanlar zaten orada olanları görmezden geliyorlar. Sanırım son on yıl veya daha uzun bir süre boyunca C ++ kullanımı hakkında öğrenilen her şeyi göz ardı ettikleri kadar yeni derleyicileri görmezden gelmek de rahat olacaklardı (örneğin, Modern C ++ Tasarımı 11 yıl önce yayınlandı - ancak insanların çoğu görünüşe göre henüz duymadınız, en basit kısımları bile çok daha az okunmuş veya anlaşılmış).

Fikriniz Java'nın arkasındaki tasarım mantığının çoğunu oluşturur. Java sizi sınıfları kullanmaya, paket hiyerarşisine göre dosya hiyerarşisini düzenlemeye, istisnaları yakalamaya vb. Zorlar. İnsanlar yine de C benzeri kod yazmayı başarırlar.

Programcılar olarak bazen en iyi çözümün teknik bir çözüm olmadığını unutuyoruz. Akran incelemeleri bu durumda en iyi bilinen çözümdür.

C ++ "tek bir doğru yol" a sahip değildir; her yaklaşımın güçlü ve zayıf yanları vardır. Çözüm yüzlerce farklı yolla yazılabilir.

Bir yazılım geliştiricisi olarak, elinizdeki görev için hangi yaklaşımın en iyi olduğuna karar vermelisiniz.

Listelediğiniz tüm şeylerin isteğe bağlı olması, daha az değil, daha fazla zarafet için bir potansiyel yarattığını düşünüyorum . Gereksizce kullanılan bir özellik gözlerimde yetersiz.

Programlamayı kullanarak çözmemiz gereken problemler birbirinden çok farklı.
Bazıları OO ilkeleri (örn. GUI'ler) kullanılarak iyi çözülmüştür, bazıları ise tamamen işlevsel bir tedaviye (örneğin sayısal şeyler) daha iyi katkıda bulunurken, bazıları en iyi şekilde düşük seviyeli "silikona yakın" bir dilde ifade edilir.

Birçok yazılımın, bu yollardan herhangi biriyle en iyi şekilde çözülen alt sorunları çözmesi gerekir. Çözümü belirli bir forma zorlamak, yalnızca amacına daha az uygun olan kodlara yol açacaktır ("daha az zarif" bile diyebilirsiniz).

Bu yüzden C ++ 'nın melezliği iyi bir şeydir - çok sayıda problemi mevcut dogmaya değil, soruna uygun bir şekilde çözmemizi sağlar .
Elbette yanlış kullanılabilir - esnek bir şey olduğunda, onu kötü bir şekilde bükme riski vardır - ancak zarafet, fad du jour'a bağlılıktan değil, dikkatli düşünce ve deneyimden gelir.