C ++ 11, std lib nesnelerini dinamik / paylaşımlı kütüphane sınırları arasında geçirme konusundaki endişelerini ele aldı mı? (yani, borçlar falan)?

C ++ hakkındaki en büyük şikayetlerimden biri, pratikte std kütüphanesi nesnelerinin dinamik kütüphanenin (yani dll / so) sınırlarının dışına aktarılmasının ne kadar zor olduğu.

Std kütüphanesi genellikle sadece başlıktır. Bazı harika optimizasyonlar yapmak için harika. Bununla birlikte, dll'ler için, genellikle bir std kütüphane konteynırlarının iç yapısını / kodunu etkileyebilecek farklı derleyici ayarlarıyla oluşturulurlar. Örneğin, MSVC'de bir dll, bir başkası onunla birlikte derlenirken yineleyicinin hata ayıklamasıyla oluşturulabilir. Bu iki eşya, etrafta std kaplarını geçen sorunlara rastlayabilir. std::stringArayüzümde ifşa edersem, müşterinin kullandığı kodun std::stringkütüphanemle tam olarak eşleştiğini garanti edemem std::string.

Bu, sorunları, baş ağrıları, vb. Hata ayıklamayı zorlaştırır. Bu sorunları önlemek için kuruluşunuzdaki derleyici ayarlarını sıkı bir şekilde denetlersiniz veya bu sorunlara sahip olmayacak daha basit bir C arayüzü kullanırsınız. Veya müşterilerinize, kullanmaları gereken beklenen derleyici ayarlarını belirtin (başka bir kitaplığın diğer derleyici ayarlarını belirlemesi durumunda berbat).

Sorum şu ki, C ++ 11 bu sorunları çözmek için bir şeyler yapmaya çalıştı mı?

Herhangi bir STL - aslında, esasen, herhangi bir üçüncü taraf kitaplığından şablon olan herhangi bir şeyin - herhangi bir genel C ++ API'sinde engellenmesi konusunda haklısınız. Ayrıca, genel C ++ API'lerinin programlanmasını bir görev haline getiren ABI kırılmasını önlemek için http://www.ros.org/reps/rep-0009.html#definition adresindeki uzun kurallar listesine de uymak istersiniz .

Ve C ++ 11 ile ilgili cevap hayır, bu standart buna dokunmuyor. Daha ilginç olan, neden olmasın? Bunun cevabı, C ++ 17'nin buna çok dokunmasıdır ve C ++ Modüllerinin uygulanabilmesi için dışa aktarılmış şablonlara ihtiyacımız vardır ve bunun için tam AST'yi diske ve sonra boşaltabilecek clang gibi bir LLVM tipi derleyiciye ihtiyacımız vardır. Herhangi bir büyük C ++ projesinde birçok ODR ihlal eden olayı ele almak için arayanlara bağımlı aramalar yapın; bu arada birçok GCC ve ELF kodu da içerir.

Son olarak, birçok MSVC nefreti ve GCC yanlısı yorumu görüyorum. Bunlar çok yanlış biçimlendirilmiş - ELF'deki GCC temelde ve geri çevrilemez bir şekilde geçerli ve doğru C ++ kodu üretemiyor. Bunun nedenleri çok ve lejyondur, ancak hızlı bir şekilde bir örnek vereceğim: ELF'deki GCC, Boost.Python'a dayanarak birden fazla uzantının Python'a yüklendiği Boost.Python kullanılarak yazılan Python uzantılarını güvenli bir şekilde üretemez. Bunun nedeni, küresel C sembol tablosuna sahip ELF'nin, segment arızalarına neden olan ODR ihlallerini önleme tasarımında basitçe yetersiz kalmasıdır; oysa ki PE ve MachO ve gerçekten de önerilen C ++ Modülleri spesifikasyonunun tümü, modül başına sembol tablolarını kullanır - bu arada, tesadüfen çok daha hızlı bir işlem süreci anlamına gelir. Ve daha birçok sorun var: son zamanlarda cevapladığım bir StackOverflow bakınhttps://stackoverflow.com/questions/14268736/symbol-visibility-exceptions-runtime-error/14364055#14364055 örneğin C ++ istisnası fırlatmasının ELF'de geri dönüşü olmayan bir şekilde bozulduğu durumlarda.

Son nokta: Farklı STL'lerin birlikte çalışılmasıyla ilgili olarak, bu, bazı STL uygulamalarına sıkı sıkıya entegre olan üçüncü taraf kütüphanelerini karıştırmaya çalışan birçok büyük kurumsal kullanıcı için büyük bir acıdır. Tek çözüm, C ++ 'nın STL birlikte çalışmayı işleyebilmesi için yeni bir mekanizmadır ve onlar da çalışmakta iken derleyici birlikte çalışmasını da düzeltebilirsiniz, böylece MSVC, GCC ve clang derlenmiş nesne dosyalarını karıştırabilirsiniz (hepsi çalışır) . C ++ 17 çalışmasını izlerdim ve önümüzdeki birkaç yıl içinde neyin ortaya çıktığını görürdüm - eğer bir şey olmazsa şaşırırdım.

Şartname hiç bu konuda bir şey yapmadı. Bunun nedeni, her bir sembolün çalışan işlemde tam olarak bir tanımı olmasını zorunlu kılan “bir tanım kuralı” kavramına sahip olmasıdır.

Windows DLL dosyaları bu gereksinimi ihlal ediyor. Bu yüzden tüm bu problemler var. Bu yüzden, C ++ standardizasyon komitesi değil, düzeltilmesi Microsoft'a kalmış. Unix bu sorunu hiç yaşamadı, çünkü paylaşılan kütüphaneler orada farklı şekilde çalışıyorlar ve varsayılan olarak tek bir tanım kuralına uyuyorlar (açıkça kırabilirsin, ama açıkçası sadece onu karşılayabileceğini ve fazladan fazla döngü atman gerektiğini biliyorsan yaparsın).

Windows DLL'ler bir tanım kuralını ihlal ediyor çünkü:

• Statik bağlantı süresi boyunca bir sembolün hangi dinamik kütüphaneden kullanılacağını kodlarlar ve bunları tanımlayan kütüphanede statik olarak semboller çözerler. Dolayısıyla, aynı zayıf sembol birden fazla paylaşılan kütüphanede ve bu kütüphanelerde tek işlemde kullanılmaya başlandıysa, dinamik bağlayıcının bu sembolleri birleştirme şansı yoktur. Genellikle bu semboller statik üyeler veya şablon örneklerinin sınıf engelleridir ve farklı DLL'lerde kodlar arasında örnekler geçerken sorunlara neden olurlar.
• Derleme sırasında zaten sembolün dinamik kütüphaneden içe aktarılıp aktarılmayacağını kodlarlar. Bu yüzden bazı kütüphanelere statik olarak bağlanmış olan kod, aynı kütüphaneye dinamik olarak bağlı olan kodla uyumlu değildir.

ELF formatı dışa aktarmayı kullanan Unix, ilk sorunu önlemek için dışa aktarılan tüm sembolleri dolaylı olarak içe aktarır ve ikincisini önlemek için statik bağlantı zamanına kadar statik ve dinamik olarak çözülmüş semboller arasında ayrım yapmaz.

Diğer konu ise derleyici bayrakları. Bu konu, çoklu derleme birimlerinden oluşan herhangi bir program için mevcuttur, dinamik kütüphanelerin dahil olması gerekmez. Ancak Windows'ta çok daha kötü. Unix'te statik veya dinamik olarak bağlantı kurup bağlamadığınız önemli değildir, hiç kimse standart çalışma zamanını herhangi bir şekilde statik olarak bağlamaz (Linux'ta yasadışı bile olabilir) ve özel bir hata ayıklama zamanı yoktur, bu nedenle bir yapı yeterince iyidir. Ancak Microsoft'un statik ve dinamik bağlantı kurma, çalışma zamanını ve hata ayıklama ve serbest bırakma yöntemlerini uygulama yöntemleri, gerekli kitaplık varyantlarının birleştirici patlamasına neden olduğu anlamına gelir. Yine C ++ dil sorunu yerine platform sorunu.

Yok hayır.

Modül adı verilen ve bunun üzerinde etkisi olabilecek, ancak kesinlikle büyük olmayan bir özellik olan başlık sisteminin yerini alacak çok iş var.