Bunun eski bir iş parçacığı olduğunu biliyorum, ancak kimse ABI arayüzlerinden veya belirli derleyici sorunlarından bahsetmedi. Ben de yapacağımı düşündüm.
Bu temelde, insanlara dağıtmak için bir başlık içeren bir kitaplık yazmanız veya kendinizi yeniden kullanmanız yerine her şeyi bir başlıkta bulundurmanız kavramına dayanır. Bir başlığı ve kaynak dosyalarını yeniden kullanmayı ve bunları her projede yeniden derlemeyi düşünüyorsanız, bu gerçekten geçerli değildir.
Temel olarak, C ++ kodunuzu derlerseniz ve bir derleyici ile bir kitaplık oluşturursanız, kullanıcı bu kitaplığı farklı bir derleyiciyle veya aynı derleyicinin farklı bir sürümüyle kullanmaya çalışır, ardından ikili uyumsuzluk nedeniyle bağlayıcı hataları veya garip çalışma zamanı davranışları alabilirsiniz.
Örneğin derleyici satıcıları, STL uygulamalarını sürümler arasında sıklıkla değiştirir. Bir kütüphanede std :: vektörü kabul eden bir fonksiyonunuz varsa, bu sınıftaki baytların kütüphane derlendiğinde düzenlendikleri şekilde düzenlenmesini bekler. Yeni bir derleyici sürümünde, satıcı std :: vector için verimlilik iyileştirmeleri yaptıysa, kullanıcının kodu farklı bir yapıya sahip olabilecek yeni sınıfı görür ve bu yeni yapıyı kitaplığınıza aktarır. Buradan her şey yokuş aşağı gidiyor ... Bu nedenle, STL nesnelerinin kütüphane sınırlarının ötesine geçmemesi tavsiye edilir. Aynısı C Çalışma Zamanı (CRT) türleri için de geçerlidir.
CRT hakkında konuşurken, kitaplığınız ve kullanıcının kaynak kodunun genellikle aynı CRT'ye bağlanması gerekir. Visual Studio ile kitaplığınızı Çok İş Parçacıklı CRT kullanarak oluşturursanız, ancak kullanıcı Çok İş Parçacıklı Hata Ayıklama CRT'sine bağlanırsa, kitaplığınız ihtiyaç duyduğu sembolleri bulamayabileceğinden bağlantı sorunları yaşarsınız. Hangi işlev olduğunu hatırlayamıyorum, ancak Microsoft Visual Studio 2015 için bir CRT işlevi satır içi yaptı. Aniden CRT kitaplığı değil, başlıkta yer aldı, bu nedenle bağlantı sırasında bulması beklenen kitaplıklar artık yapamadı ve bu bağlantı hataları oluşturdu. Sonuç olarak bu kitaplıkların Visual Studio 2015 ile yeniden derlenmesi gerekti.
Windows API kullanıyorsanız, ancak kitaplık kullanıcısına farklı Unicode ayarlarıyla derlerseniz, bağlantı hataları veya garip davranışlar da alabilirsiniz. Bunun nedeni, Windows API'nin Unicode veya ASCII dizelerini kullanan işlevlere sahip olmasıdır ve projenin Unicode ayarlarına göre doğru türleri otomatik olarak kullanan makrolar / tanımlar. Kitaplık sınırı boyunca yanlış türde bir dize geçirirseniz, çalışma zamanında işler bozulur. Veya programın ilk etapta bağlanmadığını fark edebilirsiniz.
Bu şeyler, nesneleri / türleri diğer üçüncü taraf kitaplıklarından (örneğin bir Eigen vektörü veya bir GSL matrisi) kitaplık sınırları boyunca geçirmek için de geçerlidir. 3. taraf kitaplığı, siz kitaplığınızı derlemeniz ve kullanıcınızın kodunu derlemesi arasındaki başlığını değiştirirse işler bozulacaktır.
Temelde güvenli olmak için kütüphane sınırlarından geçebileceğiniz tek şey türler ve Düz Eski Veriler (POD) şeklinde oluşturulmuştur. İdeal olarak, herhangi bir POD, kendi başlıklarınızda tanımlanan ve herhangi bir üçüncü taraf başlıklarına dayanmayan yapılarda olmalıdır.
Yalnızca başlık kitaplığı sağlarsanız, tüm kodlar aynı derleyici ayarlarıyla ve aynı başlıklara göre derlenir, bu nedenle bu sorunların çoğu ortadan kalkar (sizin ve kullanıcınızın kullandığı üçüncü kısmi kitaplıkların sürümünün API uyumlu olması koşuluyla).
Ancak, artan derleme süresi gibi yukarıda bahsedilen olumsuzluklar da vardır. Ayrıca bir işletmeyi yönetiyor olabilirsiniz, bu nedenle, herhangi birinin çalması durumunda tüm kaynak kodu uygulama ayrıntılarınızı tüm kullanıcılarınıza vermek istemeyebilirsiniz.