C ++ kitaplıklarını kullanmak neden bu kadar karmaşık?

Her şeyden önce, ben C ++ seviyorum ve C ++ Java kod daha kolay olduğunu düşünen kişilerden biri not etmek istiyorum. Küçük bir şey hariç: kütüphaneler.

Java'da, derleme yoluna biraz kavanoz ekleyebilirsiniz ve işiniz bitti.

C ++ 'da genellikle başlık dosyaları ve kitaplığın kendisi için birden çok yol ayarlamanız gerekir. Bazı durumlarda, özel yapı bayrakları bile kullanmanız gerekir. Ben esas olarak hiç Visual Studio, Kod Blokları ve hiçbir IDE kullandık. Harici kütüphanelerin kullanımı hakkında konuşurken 3 seçeneğin de pek farkı yoktur.

Acaba bunun için neden daha basit bir alternatif yapılmadı? İhtiyacınız olan her şeye sahip tek bir yerde özel bir .zip dosyası olması gibi, IDE'nin yapı bayraklarını ayarlamanız için tüm işi yapabilmesi gibi. Bunun için herhangi bir teknik engel var mı?

java c++ libraries

— Pijusn
kaynak

Yanıtlar:

C ++, nesne yönelimli programlama desteği ile daha kolay, daha otomatik bir dil yaparak C dilini geliştirmek için tasarlanmıştır. Ancak C'nin dış kütüphaneleri ve başlık dosyalarını işleme biçimini değiştirmek veya geliştirmek için hiçbir şey yapmadı. C ++ daha modern diller gibi bir modül sistemine sahip değildir - yine de C önişlemcisi ve bağlayıcı sistemini kullanır. C ++ 'ın belirtilen hedeflerinden biri C kodu ile geriye dönük uyumluluk olduğundan, bu gerçekten şaşırtıcı değildir. Herhangi bir C ++ modül sisteminin eski C başlık dosyası / bağlayıcı sistemi ile birlikte çalışması gerekir. C ++ standartlar komitesi daha modern bir modül sistemi tasarlamak için uğraşmadı. (Üzerinde çalışmasına rağmen, aşağıdaki Klaim'in yorumuna bakın.)

— Charles Salvia
kaynak

Son satır tamamen doğru değil: modüller sistemi 2004'ten beri çalışıyor (ilk belge), ancak o kadar çok iş ima etti ki, son standart için gerçekten öngörülemedi bile, çünkü uygulama eksikliği olacaktı. teklifi desteklemek. Bu uygulama, bir sonraki C ++ standardını tartmak için (diğer taslaklarla birlikte) wortk'ta olmuştur. Bu, C ++ tasarımcılarının bir önceliği değil, yanlış anlayamayacağınız, geriye dönük uyumluluk (çoğu C kodu ve C ++ 11 ile) tutmak zorunda olduğunuz özelliklerden sadece biri ve doğru şekilde elde etmek çok zor. Bu yüzden çok zaman alıyor.

— Klaim

Muhteşem. Bilgi için teşekkürler Klaim. Kesinlikle kontrol edecek. Bu çok heyecan verici :)

— Pijusn

Çoğu dil, mekanizma işletim sistemleri arasında değişiklik gösterebileceğinden bağlantıların standartlaştırılması işinin dışında kalır. Java'nın her yerde çalışma özelliği, belirli bir bağlantı ve kütüphane biçimini zorunlu kılar. Bunda yanlış bir şey yok, ama her durumda arzu edilmeyen bazı ek yükler getiriyor.

— Blrfl

Açıkçası, C ++ standartlar komitesinin dilin kendisi için bir modül sisteminde çalıştığını okumaktan oldukça korkuyorum . C ++ zaten büyük ve karmaşık bir dildir ve böyle hassas bir özellik eklemeye çalışmak çok riskli olabilir. Aşağıda Karl Bielefeldt tarafından belirtildiği gibi, bu sorun zaten platform düzeyinde (Linux paket sistemi) iyi bir çözüm buldu ve muhtemelen az çaba harcamadan çoğu IDE tarafından çok iyi ele alınabildi. Örneğin Qt Library ve Qt Creator'ın bu sorunu nasıl ele aldığına bir göz atın.

— AlexBottoni

@AlexBottoni, bu yüzyılın herhangi bir zamanında standart bir modül sistemi geliştireceklerinden şüpheliyim. Kesin uygulama konusunda anlaşamadıkları için C ++ 11'e kavramlar bile eklemediler. Başlık / bağlayıcı sistemi ile birlikte çalışan bir modül sistemi daha da zordur ve muhtemelen çok uzun bir süre görmeyiz.

— Charles Salvia

Teknik bir engel değil. Linux'ta "özel zip dosyanız", bir paket yöneticisi ile yüklediğiniz bir kütüphane-dev paketidir ve include ve bağlayıcı bayraklarını ayarlamak, şeyleri ayarlamak configure.aciçin pkg-config kullanan birkaç satır eklemek kadar basittir .

Pkg-config Windows için de mevcuttur, ancak kültürel engeller yaygın olarak benimsenmesini engellemiştir. Unix, kaynak kodu dağıtarak taşınabilirliği sağlama konusunda güçlü bir geçmişe sahiptir, bu nedenle geliştirme araçlarını ücretsiz olarak içerirler. Windows, araçlar için yalnızca ikili dağıtım ve şarj geliştiricileri teşvik etme konusunda güçlü bir geçmişe sahiptir. Para satan kütüphaneler yaptığınızda, üçüncü tarafların bunları sağlamasını kolaylaştırmak mantıklı değildir.

— Karl Bielefeldt
kaynak