Kütüphanelere bağlantı vermek yerine kaynakların kaynağını eklemeli miyim?


14

C ++ için nispeten yeniyim, bu yüzden en iyi nasıl küçük bağımlılıkları (örneğin bir komut dosyası dili veya bir JSON / YAML / XML Ayrıştırıcı) ele emin değilim.

Ayrı projeler oluşturmalı ve bunları statik kütüphane olarak bağlamalıyım mı yoksa sadece .h / .cpp dosyalarını ana projeme koymanın dezavantajları var mı?

İkincisi çok daha kolay görünüyor çünkü uyumsuz kütüphanelerle (kütüphaneyi oluştururken farklı derleyici ayarı) uğraşarak birkaç saat geçirdim, ancak C ++ 'ı yanlış şekilde öğrenmeye başlamak istemiyorum.

Bunları ayrı kitaplıklar olarak tutmak tercih edilirse, .lib / .a dosyalarının uygulamama başarıyla bağlanabilmesi için derleme bayraklarını en iyi şekilde nasıl eşitlerim?

(Şu anda MSVC 2015 ile çalışıyorum, ancak amaç XCode / clang kullanarak Mac OS X ve iOS'ta derlemek, böylece en az 3 farklı kitaplık türüyle uğraşmak zorundayım (Win x86, Mac x64, ARM) )


5
ABIss'e bakın ve onlar size
bakacaklar

1
Bazı kütüphanelerin bu şekilde kullanılması amaçlandığını unutmayın . SQLite kütüphanenin tercih edilen kullanım şekli yürütülebilir derlenmiş bir C ya da C ++ uygulaması kaynağı ağacına birleştirdi kaynağı ve başlık dosyası bırakmaktır.
Mark Benningfield

Yanıtlar:


6

TLDR;

Meli sen kaynak ekleyin? EVET
Meli X kaynak ekleyin? BAĞLI OLMAK

İşte nedeni ...

O günlerde, derleme zamanı daha küçük projelerin bile yaşadığı bir konuydu. Kaynaklarınızı derlemek ve derleyici sonuçlarını önbelleğe almak konusunda hiç endişe etmemek kesinlikle bazıları için cazipti. Bu sizin için önemli olmayan kütüphaneler için bir noktadır.

Bir başka önemli olan versiyonlamadır. Her kütüphaneyi ayrı ayrı versiyonlamanız gerekiyor mu? Her birine karşı testler mi yapıyorsunuz? Birçok ekip üyesi arasında dağıtılsın mı? Kütüphaneler yaparsanız harikadır ve dolaşmak rahattır, ancak yine de bunu umursamazsınız.

Buradaki son nokta, ek bir yüktür ve kaynak dosyaları bırakmak sizin için daha kolaydır, bu da kütüphaneleri kullanmak yerine kaynaklara düşmeye çok güçlü bir nokta verir. Fark ettiğiniz gibi, tek bir derleyici ayarı değişikliği yaptıktan sonra, tüm bağımlılıkları başka türlü izlemeniz gerekir.

Tüm bunları deneyimlerimden biliyorum:

Swift projeleri için kesinlikle çerçeveler (kütüphaneler) kullanıyorum ve Xcode kullanarak yapılandırmak kolay olduğu için bunlara bağlantı veriyorum. Ayrıca burada versiyonlamaya, testlere ve ayrışmaya gerçekten ihtiyacım var, bu yüzden.

Mono (C #) projeleri için, Unity için, projeyi kütüphanelere ayırmak için kalça yaklaşımıyla başladım, her birini derledim ve test ettim, bu harikaydı ... ama kütüphaneleri Birliğe düşürdüğümde, her türlü sorun oldu , Mono Unity'nin saldırıya uğramış versiyonundan, kodun platformları değiştirirken gösterdiği bazen farklı davranışlara kadar. Burada tüm kütüphaneleri yönetmek için tek bir IDE'nin olmaması gerçek bir acıydı, bu nedenle tüm kaynakları Unity içine koymak verimlilik için büyük bir kazançtı.

Sonunda en önemlisi, üzerinde çalıştığım bir C ++ oyun projesi. Bir oyun motoru, ağ gerçek zamanlı istemcisi, ağ HTTP istemcisi, AI ve bir kalıcılık deposu bu istemci için sadece istemci tarafında yazılmıştır. Ne seçtim? CLion + Kütüphaneler. Kütüphaneler kullanmama rağmen, öyle olduğumu hissetmedim. Tüm kaynaklar CLion IDE projesindeydi ve CMakeLists'i besteleyerek tüm yapıları tetikleyebildim ve onları tek bir vuruşta bağlayabildim.

Sonuç olarak , kütüphaneleri kullanmanın geleceğe yönelik bir çözüm olduğunu, ancak gerekmedikçe erken bir optimizasyon olduğunu söyleyebilirim. Durumunuzdan emin olabildiğim kadarıyla, birden fazla oluşturma hedefiniz olacaksa MSVC'den Xcode'a geçmek bir acı olacaktır. Bu yüzden, kitaplığı bırakmanız ve kitaplıkları kullanmanız gerekebileceği zaman için mümkün olduğunca fazla izolasyon sağlamanız yeterlidir.

Not: Bugünlerde liman işçisi ile benzer bir ikilem yaşıyorum. Yazmalı mıyım? Sadece yerel mi koşmalıyım? .. vb Ayrıca İksir, aynı uygulama içinde Uygulamalar oluşturmanıza olanak sağlar .. Bunu yapmalı mıyım? Veya uygulamayı sözde mikro hizmetlere ayırmak mı? ... vs. Gümüş mermi yok, her zaman kendinizi ölçün, YMMV olarak.


2

C ++ kitaplıklarıyla bağlantı kurmak çok uğraş gerektirir ve doğru şekilde yapmak için çok fazla bilgi ve çaba gerektirir. C ++ öğrenenlerine korkutucu olabilir.


Çoğu zaman, belirli bir C ++ kütüphanesinin yazarları / koruyucular bunu göz önünde bulunduracak ve şu ya da bu şekilde önerecektir.

Başka bir deyişle, yazarlar / koruyucular kütüphanenin başlıklar tarafından dahil edilmesini ( yalnızca * .h ve .hpp) veya kaynağa ( .h * veya .c ) dahil etmeyi planlıyorlarsa , benioku dosyasında çok açık bir şekilde söylerdi veya belgeler.


Çapraz platform olarak tasarlanan ve sürdürülen kitaplıklarda (ve birden çok C ++ derleyici satıcısı ve ortamıyla uyumlu) genellikle bir makefile sistemi veya bir derleme yapılandırma sistemi (CMake gibi) bulunur. Bu sistemler, platform farklılıklarını düzelten başlık şimleri oluşturmak ve uygun komut satırı seçeneklerini ve doğru sırayla kaynak dosyalarda derleyiciyi ve bağlayıcıyı çağıracak komut dosyaları oluşturmak için kullanılır. Platforma ve yapılandırmaya bağlı olarak, bu derleme sistemleri belirli başlıkları veya kaynak dosyalarını içerebilir veya hariç tutabilir veya belirli önişlemci sembollerini tanımlayabilir veya tanımlarını kaldırabilir.


Yazarların / bakıcıların tavsiyelerine karşı çıkmak mümkündür, ancak bu her zaman kapsamlı bir taşıma çabası gerektirir. Bu taşıma çabası için gereken iş miktarı, farklı bir C ++ ortamına taşıma ile karşılaştırılabilir.


Visual C ++, bir proje açıklama dosyasına (kısmen XML tabanlı) dayalı kendi derleme sistemini kullandığından, Linux altında kullanılan komut dosyası tabanlı derleme sisteminden oldukça farklıdır. CMake tarafından kullanılan yaklaşım, CMake'in yapılandırma ayarlarını alması ve ardından tüm Visual C ++ proje yapısını yayması ve yapılandırma seçenekleri * .vcxproj dosyalarına dönüştürülmesidir.

Visual C ++ ile C ++ bağlantısı sırasında sorunlar oluşursa, * .vcxproj dosyalarındaki derleme ayarları Visual Studio GUI (proje özellik sayfaları iletişim kutusu kullanılarak) kullanılarak değiştirilebilir. Bu, bir düzine önemli C ++ derleme ve bağlantı ayarının anlamlarını ve sonuçlarını iyice anladığınızı varsayar.

Şimdi Visual C ++ kullanmanın en aptal kısmı geliyor: Bir düzine farklı üçüncü taraf kitaplığı kullanıyorsanız, bunların tümü için oluşturma ayarlarını değiştirmek her * .vcxproj dosyasına girmek ve aynı değişikliği bir düzine GUI'de tekrarlamak anlamına gelir zamanlar. Bir güçlük, ama doğru bir şekilde nasıl yapılacağını biliyorsanız, yapılabilir.

Çoğu Visual C ++ öğrenicisi, hata kodlarıyla tanımlanan Visual C ++ derleyici ve bağlayıcı hatalarını gözlemleyerek bu ayarları zor yoldan öğrenir. Örneğin, "Sembol sembolü bir kereden fazla tanımlandı" nın yüzeysel anlamıyla LNK2005'e bakılabilir, ancak yinelenen tanımın dikkatsiz bir programlama hatasından kaynaklanmadığı anlaşılması yerine, bazılarından dolayı olabilirdi. derleme ve bağlantı seçeneklerinin çakışmaları veya yanlış uygulamaları.


Durumunuza daha spesifik ve kullanışlı bir cevap vermek için, kullanmak istediğiniz kitaplıkların adlarını ve karşılaştığınız bağlantı hatalarını veya diğer zorlukları bilmeniz gerekir. Bu soruların mevcut cevaplarını ilgili kütüphanenin tartışma panolarında bulabilirsiniz. Bu sorular "bağlantı sorunları", "pencereler" ve "görsel C ++" ile etiketlenir.

Bu konuda bir başlangıç-uzman kılavuzu mümkündür, ancak projeye özgü olacaktır. Farklı projeler tarafından seçilen farklı tercihler, rehberin tamamen yeniden yazılmasını gerektirecektir.


CMake'yi, .vcxproj'u değiştirmek yerine, .vcxproj yaymak için kullanıyorsanız, CMake yapılandırmasını
Caleth

1

Daha kolay olduğu sürece evet derim. Oldukça fazla fayda var:

  1. Özellikle Bağlantı Süresi Optimizasyonu'nu açarsanız daha hızlı ve daha iyi kod elde edilir.

  2. IDE'niz daha çok hoşuna gidecek, örneğin , kötü bir şekilde belgelenmiş kodla çalışırken çok yararlı olan (.h) arabiriminden ziyade kütüphane kodunun uygulanmasına (.cpp) atlamanıza izin verecektir (örn. çoğu kod).

  3. Genellikle bağımlılığı git bağımlılığı eklemenize izin verir. Kitaplığı güncellemeyi ve farklı sürümleri test etmeyi gerçekten kolaylaştırır.

  4. Örneğin 2017 kullanırken MSVC ++ 2013 ile bir bağımlılığın derlenmesinden endişe etmenize gerek yok. Veya statik MSVCRT ile paylaşıldı.

  5. Hata ayıklama modunda kolayca oluşturabilir ve kütüphaneye adım atabilirsiniz.

Ben düşünüyorum tek nedeni değil kütüphane büyükse ve siz, sizin örn Boost veya LLVM çoğaltmak için istemediğiniz bir kompleks inşa sistemi varsa bunu yapmak istiyor vardır. Ancak basit kütüphaneler için gerçekten dezavantaj yok.

Örnek olarak, birkaç projede libusb kullanıyorum ve Windows'u desteklemem gerekiyor. libusb, bir yapı sisteminin şakası olan ve zaten Windows'da gerçekten çalışmayan otomatik araçları kullanır. Önceden derlenmiş ikili dosyalar sağlarlar, ancak MSVC ++ 2013 ile oluşturulurlar ve 2017 ile çalışmazlar. Şimdiye kadarki en kolay çözüm , tüm ilgili .c ve .h dosyalarını projeme eklemekti.


2
1) gerçekten mi? Statik bir kütüphane, tıpkı onları derlemiş gibi, sadece bir nesne dosyaları koleksiyonudur.
Baldrickk

.oDerlenmiş dosyaların arşivini oluşturabilirsiniz , -fltoancak bunlar gerçekten statik bir kütüphane değildir - Clang için bunlar LLVM bitcode dosyalarıdır. Ve başka birinin sağladığı statik kütüphaneleri kullanırsanız kesinlikle işe yaramaz.
Timmmm

tamam, bu tartışmayı geliştirelim - Daha fazla şey öğrenmeyi dört gözle bekliyorum :)
Baldrickk
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.