İnsanların C ++ programcılarının kütüphanelerinin / ürünlerinin genel API'sini C API olarak göstermeleri gerektiğini söylediklerini sık sık duyuyorum.
Bu ne anlama geliyor ve bunun avantajları nelerdir?
İnsanların C ++ programcılarının kütüphanelerinin / ürünlerinin genel API'sini C API olarak göstermeleri gerektiğini söylediklerini sık sık duyuyorum.
Bu ne anlama geliyor ve bunun avantajları nelerdir?
Yanıtlar:
Bu, kütüphanenizin bir arayüz olarak açığa çıkan kısmının dilin yalnızca C "kısmını" kullandığı anlamına gelir, bu nedenle sınıfları veya benzerleri, yalnızca işlevleri, POD'leri ve POD'ları içeren yapıları dışa aktarmazsınız. Ayrıca, C ++ isim yönetimini, genellikle fonksiyon olarak işaretleyerek elde etmek zorunda kalmazsınız extern "C". Tipik bir örnek şöyle olabilir:
extern "C" void foo(int bar);Kütüphanelerinizi bu şekilde ortaya çıkarmanın en büyük avantajı, hemen hemen her programlama dilinin doğrudan bir C kütüphanesiyle doğrudan bağlantı kurma mekanizmasına sahip olmasıdır, ancak sadece çok az bir tanesi doğrudan bir C ++ kütüphanesiyle de doğrudan bağlantı kurabilir. Yani bu anlamda, diğer insanların kütüphanenizi kullanmasını kolaylaştırmak için en düşük ortak paydaya gidersiniz.
Ancak, diğer insanların tüketmesi için bir kütüphane üretiyorsanız, bunun gerçekten yararlı bir strateji olduğunu unutmayın. Bir parça C ++ oluşturuyorsanız - yalnızca yazılım ve kütüphanelerin birbirleriyle etkileşime girmeleri gerekiyorsa, dilin tam gücünden yararlanabilmeniz için uygun C ++ API'lerini ortaya çıkarmaktan daha iyi olursunuz (IMHO).
extern "C"alamadığım şeylerden bir örnek verebilir misin ?
.hpp, ancak bu uzantı "C ++ başlık dosyası" anlamına gelir, bu yüzden .hC ve C ++ için de kullanılmalıdır.
Timo'nun cevabına ek olarak - bazı platformlar için standartlaştırılmış bir C ++ ABI yoktur (örneğin, Windows - bazıları Mac OS X'in Linux'u gibi yaygın olarak kabul edilmiştir), bu nedenle sadece eksik özelliklerden değil, bu özelliğin uygulanmasının imkansızlığı meselesidir.
Örneğin, IIRC MSVC her sürümde farklı ABI'ye sahiptir ve hata ayıklama ya da sürüm oluşturma durumuna bağlı olarak değişebilir - ve yayınlanmadığından üçüncü taraf derleyiciler genellikle uyumlu değildir (icc'nin bazı sürümlerinin MSVC ile uyumlu olduğu hakkında bazı bilgiler okudum) 2005, ancak NDA kapsamında açıklanan bilgiler olabilir - Python'un yaratıcıları için gerekli değildir) ve kendi ABI'lerini kullanırlar. Bu yüzden pratikte dil ortamı sadece derleyici versiyonunu değil aynı zamanda bayrakları da kısıtlar.
Sonunda C ++, daha fazla derleme zamanı özelliğine sahiptir. Örneğin, jenerikler genellikle dinamik olarak yazılmış dillerde vs. yoktur.