C gibi dillerde, programcının ücretsiz aramaları eklemesi bekleniyor. Derleyici bunu neden otomatik olarak yapmıyor? İnsanlar bunu makul bir sürede yaparlar (böcekleri görmezden gelirler), bu yüzden imkansız değildir.

EDIT: Gelecekteki referans için, burada ilginç bir örnek olan başka bir tartışma.

Çünkü programın belleği tekrar kullanıp kullanmayacağı belli değil. Bu, hiçbir durumda bir algoritmanın free()her durumda ne zaman aranacağını doğru bir şekilde belirleyemediği anlamına gelir; bu, bunu yapmaya çalışan herhangi bir derleyicinin mutlaka bellek sızıntısı olan bazı programlar ve / veya serbest bırakılmış belleği kullanmaya devam eden bazı programlar üretmesi anlamına gelir. Derleyicinizin ikincisini asla yapmadığından ve programcının free()bu hataları düzeltmek için çağrı eklemesine izin vermiş free()olsanız bile, bu derleyiciyi ne zaman arayacağınızı bilmek, free()denemeyen bir derleyiciyi kullanırken ne zaman arayacağınızı bilmekten daha zor olacaktır. yardım etmek.

David Richerby'nin haklı olarak belirttiği gibi, sorun genel olarak çözülemez. Nesne canlılığı, programın küresel bir özelliğidir ve genel olarak programın girdilerine bağlı olabilir.

Kesin dinamik çöp toplama bile kesin bir problemdir! Tüm gerçek dünya çöp toplayıcıları, ulaşılabilirliği gelecekte tahsis edilmiş bir nesneye ihtiyaç duyulup duyulmayacağına muhafazakar bir yaklaşım olarak kullanır. Bu iyi bir yaklaşım, ancak yine de bir yaklaşım.

Ama bu sadece genel olarak doğru. Bilgisayar bilimi sektöründeki en ünlü kopyalardan biri "genel olarak imkansız, bu yüzden hiçbir şey yapamayız" dır. Aksine, biraz ilerleme yapmanın mümkün olduğu birçok durum var.

Referans sayımına dayanan uygulamalar, “derleyicinin ayrılması eklenmesi” ne çok yakın, öyle ki farkı söylemek zor. LLVM sitesindeki otomatik referans sayım (kullanılan Amaç-C ve Swift ) ünlü bir örnektir.

Bölge çıkarımı ve derleme zamanı çöp toplama aktif araştırma alanlarıdır. Bir nesneyi oluşturduktan sonra değiştiremeyeceğiniz ML ve Mercury gibi bildirimsel dillerde çok daha kolay olduğu ortaya çıkıyor .

Şimdi, insanlar konusunda, insanların tahsisat ömürlerini manuel olarak yönetmesinin üç ana yolu vardır:

1. Programı ve sorunu anlayarak. İnsanlar, aynı kullanım nesnesine, benzer yaşamları olan nesneleri aynı tahsisat nesnesine koyabilirler. Derleyiciler ve çöp toplayıcıları bunu çıkarmalıdır, ancak insanlar daha kesin bilgiye sahiptir.
2. Seçmeli olarak yerel olmayan defter tutma (örneğin referans sayma) veya diğer özel tahsis tekniklerini (örneğin bölgeler) yalnızca ihtiyaç duyulduğunda kullanarak. Yine, bir insan derleyicinin çıkardığı yerde bunu bilir.
3. Kötü. Sonuçta, herkes gerçek anlamda yavaş yavaş sızan programlar kullanıyor. Ya da yapmazlarsa, bazen programlar ve dahili API'lerin yeniden kullanılabilirliği ve modülerliği azaltarak bellek ömrü boyunca yeniden yapılandırılması gerekebilir.

Eksiklik problemi, kararsızlık problemi değil

Uzaklaştırma ifadelerinin en uygun şekilde yerleştirilmesinin kararsız olduğu doğru olsa da, buradaki sorun bu değil. Hem insanlar hem de derleyiciler için kararsız olduğu için, manuel ya da otomatik bir işlem olup olmadığına bakılmaksızın her zaman en uygun yerinden çıkarma yerleşimini bilerek seçmek imkansızdır. Ve hiç kimsenin mükemmel olmadığı için, yeterince gelişmiş bir derleyici, yaklaşık olarak en uygun yerleşimleri tahmin etmede insanları daha iyi performans gösterebilmelidir. Bu yüzden kararsızlık, açık bir şekilde tahsisat beyanlarına ihtiyacımızın olmasının nedeni değildir .

Dış bilginin, tahsisat beyanı yerleşimini bildirdiği durumlar vardır. Bu ifadeleri kaldırmak daha sonra operasyonel mantığın bir kısmını kaldırmaya eşdeğerdir ve bir derleyiciden otomatik olarak bu mantığı oluşturmasını istemek, ne düşündüğünü tahmin etmesini istemekle aynıdır.

Örneğin, bir Okuma-Değerlendirme-Baskı-Döngü (REPL) yazdığınızı söyleyin : kullanıcı bir komutu yazar ve programınız yürütür. Kullanıcı REPL'inize komutları yazarak belleği ayırabilir / çıkartabilir. Kaynak kodunuz, kullanıcı komut için yazdığında yeniden dağıtma da dahil olmak üzere her olası kullanıcı komutu için REPL'in ne yapması gerektiğini belirtir.

Fakat eğer C kaynak kodu, ayrılma işlemi için açık bir komut sağlamıyorsa, kullanıcı REPL'e uygun komutu girdiğinde derleyicinin konum değiştirmeyi gerçekleştirmesi gerektiği sonucuna varması gerekir. Bu komut "serbest bırakma", "özgür" veya başka bir şey mi? Derleyici, komutun ne olmasını istediğinizi bilmenin bir yolunu yoktur. Mantıksal olarak bu komut sözcüğünü aramak için programlanmış olsanız ve REPL onu bulsa bile, derleyiciye kaynak kodunda açıkça belirtmediğiniz sürece, açıklayıcı bir şekilde yanıt vermesi gerektiğini bilme yolu yoktur.

tl; dr Sorun C kaynak kodunun derleyiciye dış bilgi vermemesidir. Kararsızlık sorun değil çünkü işlemin manuel mi yoksa otomatik mi olduğu.

Şu anda, gönderilen cevapların hiçbiri tam olarak doğru değil.

Derleyiciler neden otomatik olarak tahsisat eklemiyor?

1. Bazıları yapar. (Sonra açıklayacağım.)

2. Önemsiz olarak, free()program çıkmadan hemen önce arayabilirsiniz . Ancak sorunuzun free()en kısa sürede aranması için zımni bir ihtiyaç var .

3. free()Hafızaya erişilemez ulaşılmaz herhangi bir C programında ne zaman çağrı yapılacağı sorunu çözülemez , yani sonlu bir sürede cevabı sağlayan herhangi bir algoritma için, kapsamadığı bir durum vardır. Bu - ve birçok keyfi programın kararsızlığı - Halting Probleminden kanıtlanabilir .

4. Kararsız bir problem, derleyici veya insan olsun, herhangi bir algoritma ile sınırlı bir zamanda her zaman çözülemez.

5. İnsanlar (deneyin) bir yazma alt kümesi C programlarının edebilirsiniz kendi algoritmasına (kendileri) tarafından bellek doğruluğu doğrulanması.

6. Bazı diller, derleyiciye # 5 ekleyerek # 1'i gerçekleştirir. Bellek ayırma işlemlerini keyfi kullanan programlara izin vermezler; bunun yerine, karar verilebilir alt kümelerini kullanırlar. Foth ve Rust , C'lerden daha fazla kısıtlayıcı bellek tahsisine sahip malloc(), (1) bir programın kendi kararsız setlerinin dışında yazılıp yazılmadığını tespit edebilen iki dil örneğidir .

“İnsanlar yapar, bu yüzden imkansız değil” bilinen bir yanılgıdır. Yarattığımız şeyleri mutlaka anlamayız (kontrol etmemize izin vermeyin) - para ortak bir örnektir. Teknolojik konularda, özellikle insan faktörlerinin olmadığı gibi, başarı şansımızı abartma eğilimindeyiz.

Bilgisayar programcılığındaki insan performansı çok düşüktür ve bilgisayar bilimi eğitimi (birçok mesleki eğitim programında bulunmayan) bu sorunun neden basit bir çözümü olmadığını anlamada yardımcı olur. Belki bir gün çok uzakta olmayan bir gün işinde yapay zekanın yerini alabiliriz. O zaman bile, her zaman, otomatik olarak tahsisat hakkı alan genel bir algoritma olmayacak.

Otomatik bellek yönetiminin olmaması dilin bir özelliğidir.

C'nin yazılımları kolayca yazmak için bir araç olması gerekmiyor. Bilgisayarı ne yapman gerekiyorsa yapmasını sağlamak için bir araçtır. Bu, seçtiğiniz anda hafızanın tahsis edilmesini ve ayrılmasını içerir. C, bilgisayarı tam olarak kontrol etmek istediğinizde ya da işleri dil / standart kütüphane tasarımcılarının beklediğinden farklı bir şekilde yapmak istediğinizde kullandığınız düşük seviyeli bir dildir.

Mesele, uygulamanın imkansızlığı değil, çoğunlukla tarihi bir eserdir.

Çoğu C derleyicisinin kod oluşturma şekli, derleyicinin bir anda yalnızca her kaynak dosyayı görmesidir; tüm programı bir kerede asla görmez. Bir kaynak dosya başka bir kaynak dosyadan veya bir kitaplıktan bir işlev çağırdığında, tüm derleyici, işlevin gerçek kodunu değil, işlevin dönüş türünü içeren başlık dosyasıdır. Bu, bir işaretçiyi döndüren bir işlev olduğunda, derleyicinin işaretçinin işaret ettiği hafızanın boşaltılması gerekip gerekmediğini söylemenin bir yolu olmadığı anlamına gelir. Buna karar verecek olan bilgi o zaman derleyiciye gösterilmez. Diğer taraftan, bir insan programcısı, işaretçinin ne yapılması gerektiğini bulmak için işlevin kaynak koduna veya belgelere bakmakta özgürdür.

C ++ 11 veya Rust gibi daha modern ve düşük seviyeli dilleri araştırırsanız, bu sorunu çoğunlukla işaretçinin türünde bellek sahipliğini belirgin hale getirerek sorunu çözdüklerini göreceksiniz. C ++ ' da, hafızayı tutmak için unique_ptr<T>bir ova yerine bir düzlem kullanır ve nesne ovadan farklı olarak nesne kapsamın sonuna ulaştığında hafızanın serbest T*kalmasını unique_ptr<T>sağlar T*. Programlayıcı hafızayı birinden diğerine unique_ptr<T>verebilir, ancak hafızaya sadece bir tane unique_ptr<T>işaret edebilir . Bu nedenle, hafızanın sahibi ve ne zaman serbest bırakılması gerektiğine dair her zaman açıktır.

C ++, geriye dönük uyumluluk nedenleriyle, eski stil manuel bellek yönetimine ve böylece a'nın korunmasını engellemek için hataların veya yolların oluşturulmasına izin verir unique_ptr<T>. Rust, derleyici hataları yoluyla bellek sahipliği kurallarını zorlaması nedeniyle daha da katıdır.

Kararsızlığa gelince, durma problemi ve benzerleri, evet, C anlambilimine sadık kalırsanız, belleğin ne zaman serbest bırakılacağına tüm programlar için karar vermek mümkün değildir. Bununla birlikte, çoğu gerçek program için, akademik alıştırmalar veya buggy yazılımı değil, ne zaman ve ne zaman müsaade edileceğine karar vermek kesinlikle mümkün olacaktır. Bu, insanın ilk başta ne zaman serbest kalamayacağına karar vermesinin tek sebebidir.

Diğer cevaplar, çöp toplama yapmanın mümkün olup olmadığına, bunun nasıl yapıldığına dair bazı ayrıntılara ve bazı sorunlara odaklanmıştır.

Henüz kapsanmayan konulardan biri de, çöp toplamadaki kaçınılmaz gecikmedir. C'de, bir programcı ücretsiz çağırdığında (), bu hafıza hemen kullanılabilir. (En azından teoride!) Böylece, bir programcı 100 MB'lık yapılarını serbest bırakabilir, bir 100 milisaniyelik bir sonraki 100 MB'lık bir yapı tahsis edebilir ve toplam bellek kullanımının aynı kalmasını bekler.

Bu çöp toplama ile doğru değil. Çöp toplayan sistemler kullanılmayan hafızayı öbeğe döndürmede bazı gecikmelere sahiptir ve bu önemli olabilir. 100MB yapınız kapsam dışına çıkarsa ve bir milisaniyeden sonra programınız başka bir 100 MB yapı oluşturduysa, sisteminizin kısa bir süre boyunca 200 MB kullanmasını bekleyebilirsiniz. Bu "kısa süre" sisteme bağlı olarak milisaniye veya saniye olabilir, ancak yine de bir gecikme var.

Çok fazla RAM ve sanal belleğe sahip bir bilgisayarda çalışıyorsanız, elbette bunu asla farketmeyeceksiniz. Olsa daha sınırlı kaynaklara sahip bir sistemde çalışıyorsanız (örneğin, gömülü bir sistem veya telefon), bu ciddiye almanız gereken bir şeydir. Bu sadece teorik değil - kişisel olarak bunun .NET Compact Framework kullanarak ve C # ile geliştiren bir WinCE sistemi üzerinde çalışırken problem yarattığını (cihazın tür sorunlarını düzeltirken) gördüm.

Soru, bir tahsisatın, programcının kaynak kodun diğer bölümlerinden çıkarması gereken bir şey olduğunu varsayar. Değil. "Programın bu noktasında, FOO hafıza referansı artık işe yaramaz" , yalnızca bir ustalık beyanına kodlanıncaya kadar programcının aklında bilinen bilgilerdir .

Teorik olarak diğer herhangi bir kod satırından farklı değildir. Derleyiciler neden otomatik olarak "Programın bu noktasında, giriş için BAR kayıtlarını kontrol et" veya "işlev çağrısı sıfırdan dönerse, geçerli alt programdan çıkın " ifadesini otomatik olarak yerleştirmiyorlar mı? Derleyicinin bakış açısından, sebep, bu cevapta gösterildiği gibi, "eksiklik" tir . Ancak, programcı bildiği her şeyi söylemediğinde, herhangi bir program eksiklikten muzdariptir.

Gerçek hayatta, tahrifatlar ağır iş veya kazan plakasıdır; beyinlerimiz onları otomatik olarak doldurur ve bunun hakkında homurdanır ve "derleyici bunu iyi ya da daha iyi yapabilir" duygusu doğrudur. Ancak teoride, durum böyle değil, neyse ki diğer diller bize daha fazla teori seçeneği sunsa da.

Ne olduğunu çöp toplama vardır ve referans sayımı (Objective-C, Swift) kullanılarak derleyiciler vardır: yapılır. Referans sayımı yapanların, güçlü referans çevrimlerinden kaçınarak programcının yardımına ihtiyacı vardır.

Gerçek cevabı o derleyici yazarlar yeterince iyi bir derleyici kullanılabilmesi için yeterince hızlı bir yolunu değil ise "neden". Derleyici yazarlar genellikle oldukça akıllı olduklarından, yeterince iyi ve yeterince hızlı bir yol bulmanın çok, çok zor olduğu sonucuna varabilirsiniz.

Çok, çok zor olmasının sebeplerinden biri elbette kararsız olması. Bilgisayar biliminde "karar verilebilirlik" hakkında konuştuğumuzda "doğru kararı verme" demek istiyoruz. İnsan programcılar elbette hafızayı nereye ayıracağınıza kolayca karar verebilir, çünkü doğru kararlarla sınırlı değildir . Ve sıklıkla yanlış kararlar verirler.

C gibi dillerde, programcının ücretsiz aramaları eklemesi bekleniyor. Derleyici bunu neden otomatik olarak yapmıyor?

Çünkü bir bellek bloğunun ömrü, derleyicinin değil, programcının kararıdır.

Bu kadar. Bu C'nin tasarımıdır. Derleyici bir bellek bloğu tahsis etme niyetinin ne olduğunu bilemez. İnsanlar bunu yapabilir, çünkü her hafıza bloğunun amacını bilirler ve bu amaca hizmet edildiğinde serbest bırakılabilirler. Yazılan programın tasarımının bir parçası.

C düşük seviyeli bir dildir, bu nedenle hafızanızdaki bir bloğu başka bir işleme, hatta başka bir işlemciye geçirme örnekleri oldukça sık görülür. Aşırı durumda, bir programcı kasıtlı olarak bir yığın bellek tahsis edebilir ve bir daha asla sadece sistemin diğer bölümlerine bellek baskısı yapmak için kullanmaz. Bloğun hala gerekli olup olmadığını derleyici bilmenin bir yolu yoktur.

C gibi dillerde, programcının ücretsiz aramaları eklemesi bekleniyor. Derleyici bunu neden otomatik olarak yapmıyor?

C ve diğer pek çok dilde, derleyicinin, bunun yapılması gerektiğinde derleme zamanında açık olduğu durumlarda buna eşdeğerde olmasını sağlayan bir tesis var: otomatik süre değişkenlerinin kullanılması (yani, sıradan yerel değişkenler). . Derleyici bu değişkenler için yeterli alanın düzenlenmesinden ve (iyi tanımlanmış) ömürleri sona erdiğinde o alanın serbest bırakılmasından sorumludur.

Değişken uzunluklu dizilerin C99'dan beri bir C özelliği olması durumunda, otomatik süre nesneleri, temelde C'deki hesaplanabilir sürenin dinamik olarak ayrılmış nesnelerinin yaptığı tüm işlevlere hizmet eder. Uygulamada, elbette, C uygulamaları VLA'ların kullanımına önemli pratik sınırlar koyabilir - yani büyüklükleri yığına tahsis edilmesinin bir sonucu olarak sınırlanabilir - ancak bu bir dil tasarım düşüncesi değil, bir uygulama değerlendirmesidir.

Amaçlanan kullanımı otomatik süre vermeyi engelleyen nesneler, tam olarak kullanımları derleme zamanında belirlenemeyen nesnelerdir.