C işlevleri neden adlarla karıştırılamıyor?

Son zamanlarda bir röportaj yaptım ve bir soru extern "C"C ++ kodunda kullanımının ne olduğunu sordu . C adı-mangling kullanmaz gibi C ++ kodu C işlevlerini kullanmak olduğunu yanıtladı. C'nin neden isim yönetimi kullanmadığını ve dürüst olmak gerekirse cevaplayamadığım soruldu.

C ++ derleyicisi işlevleri derlediğinde, özellikle derleme zamanında çözülmesi gereken C ++ 'da aynı adın aşırı yüklenmiş işlevlerine sahip olabileceğinden, işleve özel bir ad verdiğini anlıyorum. C de, işlevin adı aynı kalır, ya da önce _ ile birlikte kalır.

Benim sorgu: C ++ derleyicisinin C işlevlerini de değiştirmesine izin vermede sorun nedir? Derleyicinin onlara hangi isimleri verdiğinin önemli olmadığını düşünürdüm. C ve C ++ 'da işlevleri aynı şekilde çağırıyoruz.

Yukarıda bir çeşit cevap vardı, ama bazı şeyleri bağlam içine sokmaya çalışacağım.

İlk önce C önce geldi. Bu nedenle, C'nin yaptığı şey, bir çeşit "varsayılan" dır. İsimleri değiştirmez, çünkü değildir. İşlev adı, işlev adıdır. Küresel bir küreseldir, vb.

Sonra C ++ geldi. C ++, C ile aynı bağlayıcıyı kullanmak ve C ile yazılmış kodla bağlantı kurabilmek istiyordu. Ancak C ++, C'yi "mangling" (ya da eksikliği) olduğu gibi bırakamadı. Aşağıdaki örneği inceleyin:

int function(int a);
int function();

C ++ 'da, bunlar farklı gövdelere sahip farklı işlevlerdir. Bunlardan hiçbiri karıştırılmazsa, her ikisine de "işlev" (veya "_function") denir ve bağlayıcı bir sembolün yeniden tanımlanmasından şikayet eder. C ++ çözümü, bağımsız değişken türlerini işlev adına dönüştürmekti. Böylece, biri çağrılır _function_intve diğeri çağrılır _function_void(gerçek yönetim şeması değil) ve çarpışmadan kaçınılır.

Şimdi bir sorunumuz kaldı. Eğer int function(int a)bir C modülünde tanımlanmış ve biz sadece kod C ++ onun başlığını (yani beyan) alıp onu kullanıyoruz, derleyici ithalat bağlayıcı bir talimat üretecektir _function_int. İşlev tanımlandığında, C modülünde buna çağrılmadı. Denirdi _function. Bu bir bağlayıcı hatasına neden olur.

Bu hatayı önlemek için , fonksiyonun beyanı sırasında, derleyiciye bir C derleyicisi ile bağlantı kurmak veya derlemek için tasarlanmış bir işlev olduğunu söyleriz:

extern "C" int function(int a);

C ++ derleyicisi artık içe _functionaktarmayı biliyor _function_intve her şey yolunda.

Onlar "olamaz", onlar o değil değil genel olarak.

Bir C kütüphanesinde bir işlevi çağırmak istiyorsanız foo(int x, const char *y), C ++ derleyici mangle'ınızı foo_I_cCP()(ya da her neyse, sadece burada yerinde bir mangling şeması oluşturdu) içine girmesine izin vermek iyi değildir .

Bu ad çözümlenmez, işlev C'dir ve adı bağımsız değişken türleri listesine bağlı değildir. Bu yüzden C ++ derleyicisi bunu bilmeli ve mangling yapmaktan kaçınmak için bu işlevi C olarak işaretlemelidir.

Bahsedilen C işlevinin, kaynak koduna sahip olmadığınız bir kitaplıkta olabileceğini, tek sahip olduğunuz önceden derlenmiş ikili ve başlık olduğunu unutmayın. Yani C ++ derleyiciniz "bu kendi işi" yapamaz, sonuçta kütüphanede ne olduğunu değiştiremez.

C ++ derleyicisinin C işlevlerini de değiştirmesine izin vermekle ilgili sorun nedir?

Artık C işlevleri olmayacaklardı.

Bir işlev sadece bir imza ve tanım değildir; bir işlevin nasıl çalıştığı büyük ölçüde çağrı kuralı gibi faktörler tarafından belirlenir. Platformunuzda kullanım için belirtilen "Uygulama İkili Arabirimi", sistemlerin birbirleriyle nasıl konuştuğunu açıklar. Sisteminiz tarafından kullanılan C ++ ABI, bir ad yönetim şeması belirler, böylece bu sistemdeki programlar, kitaplıklardaki işlevleri nasıl çağıracağını bilir. (Harika bir örnek için C ++ Itanium ABI'yi okuyun. Neden gerekli olduğunu çok hızlı bir şekilde göreceksiniz.)

Aynı şey sisteminizdeki C ABI için de geçerlidir. Bazı C ABI'lerin aslında bir ad yönetim şeması (örn. Visual Studio) vardır, bu nedenle bu, "ad yönetimini kapatma" hakkında daha az ve belirli işlevler için C ++ ABI'den C ABI'ye geçiş hakkında daha fazladır. C işlevlerini C ABI (C ++ ABI yerine) ile ilgili olan C işlevleri olarak işaretleriz. Bildirim, tanımla eşleşmelidir (aynı projede veya bazı üçüncü taraf kütüphanelerinde olsun), aksi takdirde bildirim anlamsızdır. Bu olmadan, sisteminiz bu işlevleri nasıl bulacağınızı / çağıracağınızı bilemez.

Platformların neden C ve C ++ ABI'leri aynı olduğunu ve bu "problemden" kurtulmalarını tanımlamamasına gelince, bu kısmen tarihseldir - orijinal C ABI'leri, ad alanları, sınıflar ve operatör aşırı yüklemesi olan C ++ için yeterli değildi. bir şekilde bir sembolün adıyla bilgisayar dostu bir şekilde temsil edilmesi gerekiyor - ancak biri C ++ programlarına uymak için C programlarının haksız olduğunu C topluluğunda haksız olduğunu iddia edebilir. ABI, birlikte çalışabilirlik isteyen bazı insanlar uğruna.

Aslında MSVC yapar basit bir şekilde rağmen, mangle C isimleri. Bazen @4veya başka bir küçük sayı eklenir . Bu, çağrı kurallarına ve yığın temizleme ihtiyacına ilişkindir.

Yani öncül kusurlu.

Kısmen C ile yazılmış ve başka bir dilde kısmen yazılmış programlara sahip olmak çok yaygındır (genellikle montaj dili, ancak bazen Pascal, FORTRAN veya başka bir şey). Programların, her şey için kaynak koduna sahip olmayan farklı insanlar tarafından yazılmış farklı bileşenler içermesi yaygındır.

Çoğu platformda, bir derleyicinin belirli bir türle belirli bir türdeki argümanları kabul eden ve belirli bir türün değerini döndüren bir işlev üretmek için ne yapması gerektiğini açıklayan bir ABI [Uygulama İkili Arabirimi] adı verilen bir özellik vardır. Bazı durumlarda, bir ABI birden fazla "çağrı kuralı" tanımlayabilir; bu tür sistemler için derleyiciler genellikle belirli bir işlev için hangi çağrı kuralının kullanılması gerektiğini belirtmek için bir araç sağlar. Örneğin, Macintosh'ta, Toolbox yordamlarının çoğu Pascal çağrı kuralını kullanır, bu nedenle "LineTo" gibi bir şeyin prototipi şöyle olur:

/* Note that there are no underscores before the "pascal" keyword because
   the Toolbox was written in the early 1980s, before the Standard and its
   underscore convention were published */
pascal void LineTo(short x, short y);

Bir projedeki kodun tamamı aynı derleyici kullanılarak derlenmişse, derleyicinin her işlev için hangi adı dışa aktardığı önemli değildir, ancak birçok durumda C kodunun diğer araçlar kullanılarak derlenen işlevleri çağırması ve mevcut derleyici ile yeniden derlenemez [ve C'de bile olmayabilir]. Bağlayıcı adını tanımlayabilmek, bu tür işlevlerin kullanımı için kritik öneme sahiptir.

Gerçekleştirilen bazı teğet tartışmalara değinmek için bir cevap daha ekleyeceğim.

C ABI (uygulama ikili arayüzü) başlangıçta, yığındaki argümanları ters sırada (yani - sağdan sola itilmiş) iletmek için çağrıldı; burada arayan da yığın deposunu serbest bırakır. Modern ABI aslında argümanları geçiş argümanları için kullanır, ancak mangling düşüncelerinin çoğu o orijinal yığın argümanına geçer.

Orijinal Pascal ABI, aksine, argümanları soldan sağa itti ve callee argümanları patlatmak zorunda kaldı. Orijinal C ABI, iki önemli noktada orijinal Pascal ABI'dan üstündür. Bağımsız değişken itme sırası, ilk bağımsız değişkenin yığın ofsetinin her zaman bilinmesi anlamına gelir ve bilinmeyen sayıda bağımsız değişkene sahip işlevlere izin verir, burada erken bağımsız değişkenler kaç tane bağımsız değişken olduğunu kontrol eder (ala printf).

C ABI'nin daha üstün olduğu ikinci yol, arayan ve arayan kişinin kaç argüman olduğu konusunda anlaşamaması durumundaki davranıştır. C durumunda, sonuncuyu geçen argümanlara gerçekten erişmediğiniz sürece, kötü bir şey olmaz. Pascal'da, yığından yanlış sayıda bağımsız değişken açılır ve tüm yığın bozulur.

Orijinal Windows 3.1 ABI, Pascal'a dayanıyordu. Bu nedenle, Pascal ABI (soldan sağa argümanlar, callee çıkar) kullandı. Argüman numarasındaki herhangi bir uyuşmazlık, yığın bozulmasına neden olabileceğinden, bir karıştırma düzeni oluşturuldu. Her işlev adı, bağımsız değişkenlerinin boyutunu bayt cinsinden gösteren bir sayı ile karıştırılmıştır. Yani, 16 bit makinede aşağıdaki fonksiyon (C sözdizimi):

int function(int a)

İçin karıştırılmış oldu function@2çünkü intiki bayt genişliğinde. Bu, bildirim ve tanım uyuşmazlığı durumunda, bağlayıcının çalışma zamanında yığını bozmak yerine işlevi bulamayacağı şekilde yapılmıştır. Tersine, program bağlanırsa, çağrının sonunda yığından doğru sayıda bayt geldiğinden emin olabilirsiniz.

32 bit Windows ve sonrası için stdcallABI kullanın. Pascal ABI'ye benzer, ancak push sırası C'deki gibi sağdan sola. Pascal ABI gibi, mangling adı da yığının bozulmasını önlemek için argüman bayt boyutunu işlev adına karıştırır.

Burada başka bir yerde yapılan iddiaların aksine, C ABI, Visual Studio'da bile işlev adlarını değiştirmez. Tersine, stdcallABI spesifikasyonu ile dekore edilmiş mangling fonksiyonları VS'ye özgü değildir. GCC, Linux için derlerken bile bu ABI'yi destekler. Bu, Linux tarafından derlenen ikili dosyaların Windows derlenmiş DLL'lerine çalışma süresi bağlantısına izin vermek için kendi yükleyicisini kullanan Wine tarafından yaygın olarak kullanılır .

C ++ derleyicileri, aksi takdirde aynı olacak olan aşırı yüklenmiş işlevler için benzersiz sembol adlarına izin vermek amacıyla ad yönetimi kullanır. Temel olarak fonksiyon tabanlı bir seviyede polimorfizme izin veren argüman türlerini de kodlar.

C, fonksiyonların aşırı yüklenmesine izin vermediğinden buna ihtiyaç duymaz.

Ad yönetimi, bir 'C ++ ABI'ye güvenememenin bir (ama kesinlikle tek değil!) Nedeni olduğunu unutmayın.

C ++, ona bağlanan veya bağlandığı C kodu ile birlikte çalışabilmek ister.

C, isim tarafından yönetilmeyen işlev adlarını bekler.

C ++ onu karıştırdıysa, C'den dışa aktarılan karışık olmayan işlevleri bulamaz veya C + C'nin dışa aktardığı işlevleri bulamaz. C bağlayıcısının beklediği adı alması gerekir, çünkü C ++ 'dan geldiğini veya C ++' a gittiğini bilmiyor.

C işlevlerinin ve değişkenlerinin adlarını yönetmek, bağlantı zamanında türlerinin kontrol edilmesini sağlar. Şu anda, tüm (?) C uygulamaları bir dosyada bir değişken tanımlamanıza ve onu başka bir dosyada işlev olarak adlandırmanıza izin verir. Veya imzası yanlış olan bir işlevi bildirebilirsiniz (örn void fopen(double). Sonra da çağırabilirsiniz).

1991'de geri manevra kullanarak C değişkenlerinin ve fonksiyonlarının tip-güvenli bağlantısı için bir plan önerdim . Şema asla kabul edilmedi, çünkü burada belirtildiği gibi, bu geriye dönük uyumluluğu bozacaktır.