Standart kütüphaneler neden dil ilkellerini programlamıyor? [kapalı]


30

Niçin orada olduğunu (öğrendiğim tüm programlama dillerinde, C ++, Java, Python gibi) stdlib gibi standart kütüphanelerin, benzer "işlevlerin" dilin kendisinin ilkeli olması yerine olduğunu düşündüm.


4
"Derleyici neden bir işlev çağrısını bir komut satırına çeviremiyor?" Kabaca derleyicinin yaptığı budur, standart kütüphane olsun ya da olmasın (Tamam, Python sadece yarı yolda ve Java'dan JVM bayt koduna; benzer konsept). Standart kütüphanelerin gerçekten kod -> talimatlarının derlenmesiyle hiçbir ilgisi yoktur.
Delioth

25
@Delioth, Simone'un neden standart dil kütüphanesindeki her şeyin neden olmadığını sorduğunu düşünüyor. Programlama dillerinde çok yeni olan herkes için makul bir soru olduğunu söyleyebilirim :)
Andres F.

33
Standart kütüphane genellikle çalışan bir programlama dili ile insanların kullanacağı yararlı bir dil arasındaki boşluğu doldurur .
Telastyn

6
Python'un standart kütüphanesinin önemli bir kısmı aslında C ile yazılmış ve derlenmiştir.
ElmoVanKielmo

1
Bunun aksine, BASIC'in uygulamalarının çoğunda her şey dilin bir parçasıdır ve hiç bir kütüphanesi yoktur ve bunları desteklememektedir (çeşitli uygulamalarda, makine dilinde rutinleri çağırmak için).
Euro Micelli

Yanıtlar:


32

Vincent'ın (+1) iyi cevabını biraz genişletmeme izin ver :

Derleyici neden bir işlev çağrısını bir dizi talimata çeviremiyor?

En az iki mekanizma aracılığıyla bunu yapabilir ve yapar:

  • bir işlev çağrısının satır içi olarak yapılması - çeviri sırasında, derleyici, bir kaynak kod çağrısını, işlevi gerçek bir çağrı yapmak yerine, doğrudan satır içi ile değiştirebilir. Yine de işlevin bir yerde tanımlanmış ve standart kütüphanede olabilecek bir uygulamaya sahip olması gerekir.

  • içsel işlev - içsel işlev, derleyicinin, işlevi bir kütüphanede mutlaka işlevi bulamadan bilgilendirildiği işlevlerdir. Bunlar genellikle herhangi bir şekilde pratik olarak erişilemeyen donanım özellikleri için ayrılmıştır, o kadar basit ki, assembly dili kitaplığı çağrısının ek yükü bile yüksek sayılır. (Derleyici genellikle kaynak kodunu kendi dilinde otomatik olarak satır içi yapabilir, ancak içsel mekanizmanın geldiği montaj işlevlerini bulamaz.)

Yine de bunlar söyleniyor, en iyi seçenek bazen derleyicinin kaynak dilde bir işlev çağrısını makine kodunda bir işlev çağrısına çevirmesidir. Özyineleme, sanal yöntemler ve büyük boyutta satır içi her zaman mümkün / pratik olmamak bazı nedenlerdir. (Başka bir neden, derleme (nesne modülleri), ayrı yük birimleri (örn. DLL'ler) gibi derlemenin amacıdır).

Standart kütüphane işlevlerinin çoğunun da içsel olmasını sağlamanın gerçek bir avantajı yoktur (bu, derleyiciye gerçek bir avantaj sağlamazsa daha fazla bilgi zorlaştırır), bu nedenle bir makine kodu tekrar çağırması çoğu zaman en uygunudur.

C, standart kütüphane işlevlerini destekleyen diğer açık dil ifadelerini tartışmasız bırakan dikkat çekici bir dildir. Kütüphaneler önceden var olmasına rağmen, bu dil, standart kütüphane işlevlerinden daha fazla iş yapmaya ve dilin gramerindeki açık ifadelerden daha az çalışmasına yöneldi. Örneğin, diğer dillerde IO sık sık çeşitli ifadeler biçiminde kendi sözdizimine sahipken, C dilbilgisi herhangi bir IO ifadesi tanımlamamaktadır, bunun yerine sadece standart kütüphaneye ertelemek yerine, tüm işlev çağrıları yoluyla erişilebilir derleyici zaten nasıl yapılacağını bilir.


3
Güzel cevap Biri C'deki kararın neden verildiğini açıklamalıdır: eğer doğru hatırlıyorsam, asıl sebep aslında birçok farklı donanım mimarisi için C derleyicileri oluşturmayı kolaylaştırdı.
Doktor Brown

10
@DocBrown 1975’e gelindiğinde, programlama dili geliştirme alanında (ALGOL-68, kimse?) Herşeyi doğrudan dile getirme girişimlerinin, dil özelliklerinin her ikisinde de doğrudan yavaşlamalara yol açtığını gösteren yeterli örnekler vardı. Dil uygulamalarının üretilmesinde.
Joker_vD

5
Benzer bir örnek Python'un yaptığı şeydir print: 2.x'te, kendi özel gramerine sahip bir ifadedir , ancak 3.x'te, başka bir işlev çağrısı haline geldi. Resmi açıklama için bkz. PEP 3105 .
dan04, 23

1
@DocBrown, taşınabilirlik neredeyse kesinlikle bir neden değildi. Unix ve C yaratıldıklarında, Ken Thompson'ın başarısız Multics projesinden hangi konseptlerin kurtarılabileceğini merak ettiği için tam bir makine için tasarlandı ve üretildi. C aynı zamanda bir nedenden dolayı yaratılmıştır: Unix'i (yeniden) uygulayabilmek için yüksek seviyede bir dile sahip olmak. Temel olarak, yazılım tasarımında bir deney yapıyoruz, ticari bir çok platformlu işletim sistemi ve dilde ciddi bir girişim değil. Bkz bell-labs.com/usr/dmr/www/chist.html örneğin.
Euro Micelli

@ EuroMicelli: Orada bir çelişki görmüyorum. Ve referansınız, taşınabilirliğin ne zaman önemli hale geldiğiyle ilgili birçok ayrıntı içeriyordu, aslında C ve Unix geliştirmenin ilk yıllarındaydı. Burada sadece tahmin edebilirim, ancak C mucitleri dili kasıtlı olarak küçük tutmazlarsa, onu birçok farklı mimariye bu kadar hızlı ve başarılı bir şekilde taşımaları çok düşük olurdu.
Doktor Brown,

70

Bu sadece dilin kendisini olabildiğince basit tutmasıdır. Bir döngü türü veya parametreleri işlevlere vb. Geçirme yolları gibi dilin bir özelliği ile çoğu uygulamanın ihtiyaç duyduğu ortak işlevsellik arasında ayrım yapmanız gerekir.

Kütüphaneler, birçok programcı için faydalı olabilecek fonksiyonlardır, bu nedenle paylaşılabilen yeniden kullanılabilir kodlar olarak yaratılırlar. Standart kütüphaneler, programcıların tipik olarak ihtiyaç duyduğu yaygın işlevler olarak tasarlanmıştır. Bu şekilde programlama dili daha geniş bir programcı yelpazesi için hemen kullanışlıdır. Kütüphaneler, dilin temel özelliklerini değiştirmeden güncellenebilir ve genişletilebilir.


3
Her zaman değil. PHPÖrnek olarak, geniş dil işlevleri ile dilin kendisi arasında hiçbir fark yoktur.
Vahid Amiri

15
PHP'yi basit bir dilin örneği olarak kabul
etmem

3
@DrBreakalot PHP oldukça basit bir dildir. Bu tutarlı bir tasarıma sahip olduğunu söylemek değil, ama bu başka bir konu.
Monica

19
@LightnessRacesinOrbit PHP'yi hiç "basit" olarak adlandırmazdım: sınıf tabanlı bir nesne sistemine, ayrı bir 'ilkel değerler' kümesine, bağımsız işlevlere, nesne sistemine inşa edilmiş birinci sınıf kapanmalara, bir ad alanı mekanizmasına, çeşitli "statik" denilen kavramlar, ifadeler yanı ifadeler, sıra include, requireve require_once, eğer / için / iken (yapısal programlama), istisnalar, zayıf yazarak kuralları karmaşık 'hatası değerlerinin' ayrı bir sistem, karmaşık operatör öncelik kuralları ve uzayıp . Forth Smalltalk Şema, Prolog, vb, diyelim ki, basitliği ile karşılaştırın;)
Warbo

3
Bu cevapta açıkça belirtilmeyen ancak açıkça ifade edilmeyen ana neden, dili mümkün olduğu kadar basit tutarak, diğer platformlarda uygulamanın çok daha kolay olmasıdır. Yana standart kütüphaneler genellikle dilin kendisi yazılır , bunlar trivially taşınabilir.
BlueRaja - Danny Pflughoeft

34

Diğer cevapların söylediklerine ek olarak, standart fonksiyonları bir kütüphaneye koymak endişelerin ayrılmasıdır :

  • Dili ayrıştırmak ve bunun için kod oluşturmak derleyicinin işidir. Derleyicinin işi, o dilde yazılmış ve bir kütüphane olarak verilmiş olan herhangi bir şeyi içermek değildir.

  • Neredeyse tüm programların ihtiyaç duyduğu temel işlevleri sağlamak, standart kütüphanenin (her zaman dolaylı olarak kullanılabilir olan) işidir . Yararlı olabilecek tüm fonksiyonları içermesi standart kütüphanenin işi değildir.

  • Birçok programın yapmadan yapabileceği, ancak birçok uygulamanın standart ortamlarda gönderilmesini garanti altına almak için hala temel olan ve aynı zamanda gerekli olan yardımcı işlevsellik sağlamak isteğe bağlı standart kitaplıkların işidir. Bu isteğe bağlı kitaplıkların işi, şimdiye kadar yazılmış tüm yeniden kullanılabilir kodları içermesidir.

  • Yararlı yeniden kullanılabilir fonksiyonların koleksiyonlarını sağlamak kullanıcı kütüphanelerinin işidir. Yazılan tüm kodu içeren kullanıcı kütüphanelerinin işi değildir.

  • Bir uygulamanın kaynak kodunun işi, geriye kalan kod parçalarını yalnızca o uygulamayla gerçekten alakalı olarak sağlamaktır.

Her bedene uyan tek bir yazılım istiyorsanız, delice karmaşık bir şey elde edersiniz. Karmaşıklığı yönetilebilir seviyelere indirmek için modüler hale getirmeniz gerekir. Kısmi uygulamalara izin vermek için modüler hale getirmeniz gerekir :

  • Iş parçacığı kitaplığı, tek çekirdekli yerleşik denetleyicisinde değersizdir. Bu gömülü denetleyicinin dil uygulamasının yalnızca pthreadkitaplığı içermesini sağlamak, yapılacak en doğru şeydir.

  • Matematik kütüphanesi bir FPU'su olmayan mikro denetleyicide değersizdir. Yine, bu gibi işlevler sağlamaya zorlanmamak sin(), yaşamı, o mikro denetleyici için kendi dil uygulayıcıları için kolaylaştırır.

  • Çekirdek programlarken çekirdek standart kütüphanesi bile değersizdir. Sen uygulayamaz write()çekirdeğin içine bir sistem çağrısı olmadan ve siz uygulayamaz printf()olmadan write(). Bir çekirdek programcısı olarak, sistemi write()çağırmak sizin işinizdir , orada olmasını bekleyemezsiniz.

Standart kütüphanelerden bu tür ihmallere izin vermeyen bir dil, birçok görev için uygun değildir . Dilinizin alışılmadık ortamlarda esnek bir şekilde kullanılabilir olmasını istiyorsanız, hangi standart kitaplıkların dahil edilmesinde esnek olması gerekir. Diliniz standart kitaplıklara ne kadar güvenirse, yürütme ortamında o kadar fazla varsayım yapar ve bu nedenle bu ön koşulları sağlayan ortamlarda kullanımını kısıtlar.

Tabii ki, python ve java gibi yüksek seviyeli diller , çevreleri hakkında birçok varsayım yapabilir . Ve standart kütüphanelerine pek çok şey ekleme eğilimindedirler. C gibi daha düşük seviyeli diller standart kütüphanelerinde çok daha az sağlar ve çekirdek standart kütüphanesini çok daha küçük tutar. Bu nedenle, hemen hemen her mimari için çalışan bir C derleyicisi bulursunuz, ancak üzerinde hiçbir python komut dosyası çalıştıramayabilirsiniz.


16

Derleyicilerin ve standart kitaplıkların ayrı olmasının büyük bir nedeni, iki farklı amaca hizmet etmeleridir (her ikisi de aynı dil spesifikasyonuyla tanımlanmış olsalar bile): derleyici daha üst düzey kodları makine talimatlarına çevirir ve standart kitaplık önceden test edilmiş sınama sağlar Yaygın olarak ihtiyaç duyulan işlevselliğin uygulamaları. Derleyici yazarları, diğer yazılım geliştiricilerin yaptığı gibi modülerliğe de değer verir. Aslında, ilk C derleyicilerinden bazıları, derleyiciyi ön işleme, derleme ve bağlantı için ayrı programlara böler.

Bu modülerlik size birçok avantaj sağlar:

  • Yeni bir donanım platformunu desteklerken gereken iş miktarını en aza indirir, çünkü standart kitaplık kodunun çoğu donanım-agnostik olarak yeniden kullanılabilir.
  • Standart bir kütüphane uygulaması farklı şekillerde optimize edilebilir (hız, alan, kaynak kullanımı vb.). Birçok erken hesaplama sisteminde yalnızca bir derleyici mevcuttu ve ayrı bir standart kütüphaneye sahip olmak, geliştiricilerin ihtiyaçlarını karşılamak için uygulamaları değiştirebilecekleri anlamına geliyordu.
  • Standart kütüphane işlevselliği bile mevcut değildir. Örneğin, çıplak metal C kodu yazarken, tam özellikli bir derleyiciniz var, ancak standart kütüphane işlevlerinin çoğu orada değil ve dosya G / Ç gibi bazı şeyler bile mümkün değil. Derleyicinin bu işlevi gerçekleştirmesi gerekiyorsa, en çok ihtiyaç duyduğunuz platformlarda standartlara uygun bir C derleyiciniz olamazdı.
  • Eski sistemlerde, derleyicileri, donanımı tasarlayan şirket tarafından sık sık geliştirilmiştir. Standart kütüphaneler, işletim sistemi sağlayıcısı tarafından sıklıkla sağlanmıştır, çünkü genellikle bu yazılım platformuna özgü işlevselliklere (sistem çağrıları gibi) erişmeleri gerekirdi. Bir derleyici yazarın, farklı donanım ve yazılım kombinasyonlarını desteklemesi gerekmiyordu (hem donanım mimarisi hem de yazılım platformunda çok daha fazla çeşitlilik vardı).
  • Yüksek seviyeli dillerde, dinamik olarak yüklenmiş bir kütüphane olarak standart bir kütüphane uygulanabilir. Bir standart kütüphane uygulaması daha sonra birden fazla derleyici ve / veya programlama dili tarafından kullanılabilir.

Tarihsel olarak konuşursak (en azından C'nin bakış açısından), dilin orijinal, standartlaştırma öncesi sürümlerinin standart bir kütüphanesi yoktu. İşletim sistemi satıcıları ve üçüncü taraflar, sıklıkla kullanılan işlevselliklerle dolu kitaplıklar sunacaklardır, ancak farklı uygulamalar farklı şeyler içeriyordu ve bunlar büyük ölçüde birbiriyle uyumlu değildi. C standartlaştırıldığında, bu farklı uygulamaları uyumlu hale getirmek ve taşınabilirliği geliştirmek için bir "standart kütüphane" tanımladılar. C standart kütüphanesi, Boost kütüphanelerinin C ++ 'a sahip olduğu gibi dilden ayrı olarak geliştirildi, ancak daha sonra dil spesifikasyonuna entegre edildi.


6

Ek köşe-cevap: Fikri mülkiyet yönetimi

Dikkate değer bir örnek, Microsoft tarafından Intel'den satın alınan ve çerçeve açık kaynaklı olsa bile açıklanmayan şekilde kaldığı .NET Framework'te Math.Pow uygulamasının (çift, çift) uygulanmasıdır . (Kesin olmak gerekirse, yukarıdaki durumda bu bir kütüphane yerine dahili bir çağrıdır ancak fikir saklanır.) Dilin kendisinden ayrılmış bir kütüphane (teorik olarak standart kütüphanelerin bir alt kümesi), dilin destekçilerini çizim konusunda daha fazla esneklik sağlayabilir. şeffaflığı koruyacak olanlar ile açıklanamayanlar arasındaki sınır (üçüncü taraflarla yapılan sözleşmeler veya IP ile ilgili diğer nedenlerle).


Bu kafa karıştırıcı. Hakkında bağlantı verdiğiniz sayfa Math.Pow, herhangi bir satın alma işleminden veya Intel ile ilgili herhangi bir şeyden bahsetmiyor ve işlevin uygulanmasının kaynak kodunu okuyan kişilerden bahsediyor.
Monica

@LightnessRacesinOrbit - hm, hala orada görebiliyorum ("intel" i ararken). Ayrıca, son kaynak kodun referansını (en son yorumlarda) ve ayrıca kamuya açık olan ancak karmaşıklığı ve yorumlanan verimsizliği alternatif uygulamanın neden açıklanmadığını gösteren bir ipucu veren alternatif bir uygulamaya (ikinci cevapta) ulaşabilirsiniz. Gerçekten verimli uygulama, kamuya açık alanda mutlaka bulunmaması gereken CPU düzeyinde birçok ayrıntı hakkında derinlemesine bilgi gerektirebilir.
miroxlav

5

Hatalar ve hata ayıklama.

Hatalar: Tüm yazılımlarda hatalar, standart kütüphanenizde hatalar ve derleyicinizde hatalar var. Dilin bir kullanıcısı olarak, derleyicinin aksine standart kütüphanedeyken bu tür hataları bulmak ve çözmek çok daha kolaydır.

Hata ayıklama: Standart bir kütüphanenin yığın izini görmem ve bana nelerin yanlış olabileceği konusunda bir fikir vermem çok daha kolay. Çünkü o yığın izlemede anladığım bir kod var. Elbette daha derine inebilir ve kendi içsel işlevlerinizi takip edebilirsiniz, ancak günden güne her zaman kullandığınız bir dilde ise çok daha kolaydır.


5

Bu mükemmel bir soru!

Teknoloji harikası

Örneğin, C ++ Standardı derleyicide veya standart kütüphanede ne yapılması gerektiğini asla belirtmez: sadece uygulamaya atıfta bulunur . Örneğin, ayrılmış semboller hem derleyici (içsel olarak) hem de standart kütüphane tarafından birbirinin yerine kullanılabilir.

Yine de, bildiğim tüm C ++ uygulamaları, derleyici tarafından sağlanan asgari sayıda özgün ve standart kütüphane tarafından sağlanan mümkün olacaktır.

Bu nedenle, standart kütüphaneyi derleyicideki gerçek işlevsellik olarak tanımlamak teknik olarak mümkün olsa da pratikte nadiren kullanılmaktadır.

Niye ya?

Bazı işlevsellik parçasını standart kütüphaneden derleyiciye taşıma fikrini düşünelim.

Avantajları:

  • Daha iyi tanılama: gerçekler özel kasalı olabilir.
  • Daha iyi performans: gerçekler özel kasalı olabilir.

Dezavantajları:

  • Artan derleyici kütlesi: Her bir özel durum derleyiciye karmaşıklık katar; karmaşıklık bakım maliyetlerini ve hata olasılığını artırır.
  • Daha yavaş yineleme: işlevselliğin uygulanmasının değiştirilmesi, derleyicinin değiştirilmesini gerektirir, stddenemenin yalnızca küçük bir kütüphane oluşturmasını zorlaştırır .
  • Girişte daha yüksek bar: Bir şeyi değiştirmek ne kadar pahalı / zorsa, o kadar az insanın atlaması muhtemeldir.

Bu, bir şeyi derleyiciye taşımanın şimdi ve gelecekte pahalı olduğu ve bu nedenle sağlam bir vaka gerektirdiği anlamına gelir . Bazı işlevsellik parçaları için gereklidir (normal kod olarak yazılamazlar), ancak o zaman bile derleyiciye taşınmak ve üzerlerine standart kitaplıkta inşa etmek için asgari ve genel parçaları çıkarmak gerekir.


5

Kendim bir dil tasarımcısı olarak, buradaki diğer cevapların bazılarını tekrar etmek istiyorum, ancak bunu bir dil inşa eden birinin gözünden sağlamak istiyorum.

Yapabileceğiniz her şeyi eklemeyi tamamladığınızda bir API bitmez. Yapabileceğiniz her şeyi almayı tamamladığınızda bir API biter.

Bazı dilleri kullanarak bir programlama dili belirtilmelidir. Kendi dilinizde yazılmış herhangi bir programın arkasındaki anlamı aktarabilmelisiniz. Bu dili yazmak çok zordur ve iyi yazmak bile zordur. Genel olarak, bilgisayara değil, diğer geliştiricilere, özellikle de diliniz için derleyiciler veya tercümanlar yazan geliştiricilere anlam vermek için kullanılan çok kesin ve iyi yapılandırılmış bir İngilizce biçimi olma eğilimindedir. İşte C ++ 11 spec, [intro.multithread / 14] 'den bir örnek:

Bir atomik nesne M üzerindeki B değeri hesaplamasına göre görünür yan etki dizisi, M'nin modifikasyon sırasındaki en büyük bitişik yan etki dizisidir, burada birinci yan etki B'ye göre görülebilir ve her yan etki için, B'nin kendisinden önce olduğu durum böyle değildir. B değerlendirmesiyle belirlenen bir M atomik objesinin değeri, B'ye göre M'nin görünür sırasındaki bazı işlemler tarafından kaydedilen değer olacaktır. hesaplama aşağıdaki tutarlılık gereklilikleri göz önüne alındığında benzersizdir. — Notu yaz]

Blek! C ++ 11'in çoklu okuyucuyu nasıl idare ettiğini kavramaya başlamış olan herkes, ifadelerin neden bu kadar sımsıkı olmak zorunda olduğunu takdir edebilir, ancak bu, onun ... gerçekten de ... opak olduğu gerçeğini affetmez!

Kontrast bu tanımı ile std::shared_ptr<T>::resetstandart kütüphane bölümünde:

template <class Y> void reset(Y* p);

Etkileri: Eşdeğerishared_ptr(p).swap(*this)

Öyleyse fark nedir? Dil tanımı bölümünde, yazarlar okuyucunun dil ilkellerini anladığını varsayamazlar. Her şey İngilizce nesirinde dikkatlice belirtilmelidir. Kütüphane tanımı bölümüne girince, davranışı belirtmek için dili kullanabiliriz. Bu genellikle çok daha kolaydır!

Prensip olarak, bir kişi ilk belgenin başlangıcında ilkellerden, “ilkel ilkeler” ile bir çizgi çizmeye gerek kalmadan “standart kütüphane özellikleri” olarak ne düşüneceğimizi tanımlayarak pürüzsüz bir birikime sahip olabilir. "standart kütüphane" özellikleri. Uygulamada, bu çizgi çizilmesi çok değerlidir çünkü dilin en karmaşık bölümlerinden bazılarını (algoritmaları uygulaması gerekenler gibi) onları ifade etmek için tasarlanmış bir dil kullanarak yazmanıza izin verir.

Ve biz gerçekten bulanık çizgiler görüyoruz:

  • Java'da, java.lang.ref.Reference<T>olabilir sadece standart kütüphane sınıfları tarafından alt sınıflanamayacağını java.lang.ref.WeakReference<T> java.lang.ref.SoftReference<T>ve java.lang.ref.PhantomReference<T>çünkü davranışları Referenceöylesine derinden onlar "standart kitaplığı" sınıfları olarak uygulanan bu sürecin bölümüne bazı kısıtlamalar koymak için gerekli Java dili spesifikasyonu ile dolaşık vardır.
  • C # 'da delegeler kavramını içine alan bir sınıf System.Delegate vardır. İsmine rağmen, bir temsilci değil. Ayrıca türetilmiş sınıfları oluşturamadığınız soyut bir sınıftır (başlatılamaz). Sadece sistem, dil belirtiminde yazılan özellikleri kullanarak yapabilir.

2

Bu, mevcut cevaplara bir ek olarak verilmiştir (ve yorum için çok uzun).

Standart bir kütüphane için en az iki neden var:

Giriş engeli

Belirli bir dil özelliği bir kütüphane işlevindeyse ve nasıl çalıştığını bilmek istersem, bu işlev için yalnızca kaynağı okuyabilirim. Bir hata raporu / yama / çekme isteği göndermek istersem, bir düzeltme ve test senaryoları düzenlemek için genellikle zor değildir. Derleyicideyse, iç kısımlara girebilirim. Aynı dilde olsa bile (ve öyle olmalı, kendine saygı duyan herhangi bir derleyici kendi kendine barındırılmalıdır) derleyici kodu uygulama koduna benzemez. Doğru dosyaları bulmak bile sonsuza kadar sürebilir.

O rotaya giderseniz, kendinizi potansiyel bir katkıda bulunanlardan kesiyorsunuz.

Sıcak kod yükleme

Birçok dil bu özelliği bir dereceye kadar sunar, ancak sıcak yüklemeyi yapan kodu sıcak olarak yeniden yüklemek oldukça karmaşık olacaktır. SL çalışma zamanından ayrıysa yeniden yüklenebilir.


3
"Kendine saygı duyan herhangi bir derleyici kendi kendine barındırılmalıdır" - hiç de değil. Tüm bu dilleri derlemek için C, C ++, Objective-C, Swift, Fortran ve benzeri dillerde yazılmış LLVM sürümlerinin olması anlamsız olacaktır.
gnasher729

@ gnasher729 bu biraz özel bir durum değil mi (CLR gibi diğer çoklu dil hedefleriyle birlikte)?
Jared Smith,

@ JaredSmith şimdi genel bir durum olduğunu söyleyebilirim, hiç özel değil. Artık hiç kimse monolitik bir uygulama olarak "derleyici" yazmıyor. Bunun yerine derleyici sistemleri üretirler . Tam derleyicinin işlevselliğinin çoğu, derlenen belirli dilden tamamen bağımsızdır ve dile bağlı bölümlerin çoğu , her dilin kodunu yazarak değil, dilin dilbilgisini tanımlayan farklı veriler sağlayarak yapılabilir. derlemek istiyorum.
alephzero

2

Bu ilginç bir soru ama daha önce verilmiş çok sayıda iyi cevap var, bu yüzden tam bir cevap almayacağım.

Ancak, sanmadığım iki şey yeterince dikkat çekti:

İlk olarak, her şeyin süper net bir kesim olmadığı. Bu tam olarak bir spektrum biraz çünkü işleri farklı yapmak için sebepler var. Örnek olarak, derleyiciler genellikle standart kütüphaneleri ve işlevlerini bilir. Örnek olarak: C'nin "Merhaba Dünya" fonksiyonu - printf - aklıma gelen en iyisi. Bu bir kütüphane işlevidir, bir tür olması gerekir, çünkü çok platform bağımlıdır. Ancak programcının kötü çağrılar hakkında uyarılması için davranışının (uygulama tarafından tanımlanmış) derleyici tarafından bilinmesi gerekir. Bu özellikle temiz değil, ancak iyi bir uzlaşma olarak görülüyordu. Bu arada, bu "neden bu tasarımın" sorularının çoğunun gerçek cevabı: çok fazla uzlaşma ve "o zaman iyi bir fikir gibi göründü". Her zaman değil, "bunu yapmanın net yoluydu" ya da "

İkincisi, standart kütüphanenin bu kadar standart olmamasını sağlamasıdır. Bir dilin arzulandığı birçok durum vardır ancak genellikle onlara eşlik eden standart kütüphaneler hem pratik hem de arzu edilebilir değildir. Bu genellikle standart olmayan platformlarda C gibi programlama dilleri olan sistemlerde geçerlidir. Örneğin, işletim sistemi veya zamanlayıcı olmayan bir sisteminiz varsa: iş parçacığınız olmayacak.

Standart bir kütüphane modelinde (ve içinde iş parçacığı destekleniyorsa) bu, temiz bir şekilde işlenebilir: derleyici hemen hemen aynıdır, geçerli kitaplıkların bitlerini yeniden kullanabilirsiniz ve kaldırmayacağınız herhangi bir şey. Bu derleyici içine pişmiş ise işler karışmaya başlar.

Örneğin:

  • Uyumlu bir derleyici olamazsınız.

  • Standarttan sapmanızı nasıl belirtirsiniz? Genellikle, başarısız olabileceğiniz bazı ithalat / içerme sözdizimlerinin bir biçimi olduğunu unutmayın; örneğin, standart kütüphane modelinde eksik olan herhangi bir şey varsa, pitonların ithalatı veya C'leri sorunu kolayca işaret eder.

Ayrıca 'kütüphane' işlevini değiştirmek veya uzatmak istiyorsanız da benzer sorunlar uygulanır. Bu düşündüğünden çok daha yaygın. Sadece diş açmaya devam etmek için: pencereler, linux ve bazı egzotik ağ işleme üniteleri hepsi farklı şekilde diş açıyor. Linux / windows bitleri oldukça statik olabilir ve aynı bir API kullanabilse de, NPU işleri haftanın günleri ve onunla birlikte API ile değişecektir. Derleyiciler, bu tür bir şeyi ayırmanın bir yolu olmadığında, hangi bitleri hızlı bir şekilde desteklemeleri / yapabilecekleri konusunda karar vermeleri gerektiğine karar verdiklerinde derhal sapma yaparlar.

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.