Uzun zamandır bir C # programcısı olarak, yakın zamanda Kaynak Edinimi Başlatma'nın (RAII) avantajları hakkında daha fazla şey öğrenmeye başladım . Özellikle, C # deyiminin olduğunu keşfettim:

using (var dbConn = new DbConnection(connStr)) {
    // do stuff with dbConn
}

C ++ eşdeğeri var:

{
    DbConnection dbConn(connStr);
    // do stuff with dbConn
}

yani DbConnectionbir usingblokta olduğu gibi kaynak kullanımını kullanmayı hatırlamak C ++ 'da gereksizdir! Bu C ++ 'nın büyük bir avantajı gibi görünüyor. Eğer türün örneği üyesi olan bir sınıf göz önüne aldığımızda bu daha da ikna edici DbConnectionörneğin,

class Foo {
    DbConnection dbConn;

    // ...
}

C # 'da Foo'nun IDisposableböyle bir uygulamasına ihtiyacım olacak :

class Foo : IDisposable {
    DbConnection dbConn;

    public void Dispose()
    {       
        dbConn.Dispose();
    }
}

Daha da kötüsü, her kullanıcının bir bloğa Fooyerleştirmeyi hatırlaması gerekir , örneğin:Foousing

   using (var foo = new Foo()) {
       // do stuff with "foo"
   }

Şimdi C # 'ya ve Java köklerine baktığımda merak ediyorum ... Java geliştiricileri, yığını yığında bıraktıklarında bıraktıkları şeyleri tam olarak takdir ettiler mi?

(Benzer şekilde, Stroustrup RAII'nin önemini tam olarak takdir etti mi?)

Şimdi C # 'ya ve Java köklerine baktığımda merak ediyorum ... Java geliştiricileri, yığını yığında bıraktıklarında bıraktıkları şeyleri tam olarak takdir ettiler mi?

(Benzer şekilde, Stroustrup RAII'nin önemini tam olarak takdir etti mi?)

Gosling’in Java’yı tasarladığı sırada RAII’nin önemini anlamadığından eminim. Görüşmelerinde sık sık jenerik ve operatör aşırı yüklemesinin dışlanma nedenlerinden bahsetti, ancak deterministik yıkıcılardan ve RAII'den asla bahsetmedi.

Yeterince komik, Stroustrup bile deterministik yıkıcıların tasarladıkları zamandaki öneminin farkında değildi. Teklifi bulamıyorum, ancak gerçekten ilgiliyseniz, burada yaptığı röportajlar arasında bulabilirsiniz: http://www.stroustrup.com/interviews.html

Evet, C # (ve, eminim, Java) tasarımcıları deterministik sonlandırmaya karşı özellikle karar verdi. Anders Hejlsberg'e 1999-2002 yılları arasında bu defalarca sordum.

İlk olarak, yığın ya da yığın temelli olup olmadığına dayanan bir nesne için farklı anlambilim fikri, her iki dilin birleştirici tasarım hedefine kesinlikle aykırı olduğu ve bu tür programcıları tam anlamıyla çözdüğü yönündedir.

İkincisi, avantajların olduğunu kabul etseniz bile, defter tutmakla ilgili önemli uygulama karmaşıklıkları ve verimsizlikleri vardır. Sen olamaz gerçekten yönetilen bir dilde yığın yığın benzeri nesneler koydu. "Yığın benzeri anlambilim" deme ve önemli bir çalışmaya bağlı kalmanız (değer türleri zaten yeterince zor, karmaşık bir sınıfın örneği olan, referansların tekrar girip tekrar belleğe girmesiyle ilgili bir nesne düşünün).

Bu nedenle, "(neredeyse her şeyin bir nesne olduğu" bir programlama sistemindeki her nesne üzerinde deterministik bir sonlandırma istemezsiniz. Yani do deterministik tamamlanmasını sahiptir birinden normalde izlenen nesneyi ayırmak için programcı kontrollü sözdizimi çeşit tanıtmak zorundayız.

C # 'da, usingC # 1.0 olanın tasarımında oldukça geç gelen bir anahtar kelimeye sahipsiniz . Her IDisposableşey oldukça saçma ve bir kazan-plaka modelinin otomatik olarak uygulanabileceği sınıfları işaretleyen usingC ++ yıkıcı sözdizimi ile çalışmak daha şık olurdu, diye merak ediyor musunuz?~IDisposable

Java'nın 1991-1995'te, C ++ 'ın çok farklı bir dil olduğu zaman geliştirildiğini unutmayın. İstisnalar (RAII'yi gerekli kılan ) ve şablonlar (akıllı işaretçilerin uygulanmasını kolaylaştıran) "yeni fanglı" özelliklerdi. Çoğu C ++ programcısı C'den gelmişti ve manuel bellek yönetimi için kullanılıyordu.

Bu yüzden Java'nın geliştiricilerinin kasıtlı olarak RAII'yi bırakmaya karar verdiğinden şüpheliyim. Bununla birlikte, Java'nın değer semantiği yerine referans anlambilimini tercih etmesi kasıtlı bir karardı. Deterministik yıkımı referans anlamsal bir dilde uygulamak zordur.

Öyleyse neden değer anlambilimi yerine referans anlambilimi kullanıyorsunuz?

Çünkü dili çok daha basit hale getiriyor .

• Arasında bir sözdizimsel ayrım için gerek yoktur Foove Foo*ya arasındaki foo.barve foo->bar.
• Tüm atamaların bir işaretçiyi kopyalaması gerektiğinde aşırı atama yapılmasına gerek yoktur.
• Kopyalama kurucularına gerek yoktur. ( Zaman zaman bunun gibi açık bir kopyalama işlevine clone()ihtiyaç duyulabilir. Çoğu nesnenin kopyalanması gerekmez. Örneğin, değiştirilemez.)
• privateKopya kurucuları ilan etmeye ve operator=bir sınıfı tartışılmaz hale getirmeye gerek yoktur . Bir sınıfın nesnelerinin kopyalanmasını istemiyorsanız, kopyalamak için bir fonksiyon yazmazsınız.
• swapİşlevlere gerek yoktur . (Bir sıralama rutini yazmıyorsanız.)
• C ++ 0x stili değer referanslarına gerek yoktur.
• (N) RVO'ya gerek yoktur.
• Dilimleme problemi yok.
• Derleyicinin nesne düzenlerini belirlemesi daha kolaydır, çünkü referanslar sabit bir boyuta sahiptir.

Referans anlambiliğinin ana dezavantajı, her nesne potansiyel olarak kendisine birden fazla referans verdiğinde, ne zaman silineceğini bilmek zorlaşır. Hemen hemen otomatik bellek yönetimine sahip olmalısınız .

Java, deterministik olmayan bir çöp toplayıcıyı kullanmayı seçti.

GC deterministik olamaz mı?

Evet yapabilir. Örneğin, Python'un C uygulaması referans sayımı kullanır. Ve daha sonra yeniden sayımların başarısız olduğu döngüsel çöpleri işlemek için GC izleme eklendi.

Ancak tazminat korkunç verimsizdir. Sayıları güncellemek için çok sayıda CPU döngüsü harcandı. Bu güncellemelerin senkronize edilmesi gereken çok iş parçacıklı bir ortamda (Java'nın tasarlandığı tür gibi) daha da kötüsü. Boş çöp toplayıcısını kullanmak, diğerine geçmek zorunda kalana kadar çok daha iyi .

Java'nın, dosyalar ve soketler gibi elverişsiz kaynaklar pahasına ortak vakayı (belleği) optimize etmeyi seçtiğini söyleyebilirsiniz. Bugün, RAII'nin C ++ 'a benimsenmesi ışığında, yanlış seçim gibi görünebilir. Ancak, Java için hedef kitlenin çoğunun, bu tür şeyleri açıkça kapatmak için kullanılan C (veya "sınıflı C") programcıları olduğunu unutmayın.

Peki ya C ++ / CLI "yığın nesneleri"?

Onlar sadece konum için sözdizimsel şekerDispose ( orijinal bağlantı çok C # gibi) using. Bununla birlikte, genel deterministik imha sorununu çözmez, çünkü bir anonim oluşturabilirsiniz gcnew FileStream("filename.ext")ve C ++ / CLI bunu otomatik olarak elden çıkarmayacak.

Java7, C # 'ya benzer bir şey sundu using: “kaynakları denemek” ifadesi

bir tryveya daha fazla kaynak bildiren bir ifade. Bir kaynak , programın bitmesinden sonra kapatılması gereken bir nesnedir. try-With-kaynaklar deyimi her kaynak deyimi sonunda kapalı olmasını sağlar. java.lang.AutoCloseableUygulayan tüm nesneleri içeren , uygulayan herhangi bir nesne, java.io.Closeablekaynak olarak kullanılabilir ...

Bu yüzden, ya bilinçli olarak RAII'yi uygulama yapmamayı seçtiler ya da bu arada fikrini değiştirdiler.

Java kasıtlı olarak yığın tabanlı nesnelere (aka değer nesneleri) sahip değildir. Bunlar, böyle bir yöntemin sonunda nesnenin otomatik olarak imha edilmesi için gereklidir.

Bu ve Java'nın çöp toplandığı gerçeğinden dolayı, deterministik sonlandırma daha az ya da çok imkansızdır (örneğin. "Yerel" nesnem başka bir yere başvurulmuşsa ne olur? Sonra yöntem bittiğinde, imha edilmesini istemeyiz.) ) .

Bununla birlikte, bu çoğumuz için iyidir, çünkü yerel (C ++) kaynaklarla etkileşimde bulunmak dışında, neredeyse hiçbir zaman deterministik sonlandırmaya ihtiyaç duyulmaz !

Java neden yığın tabanlı nesnelere sahip değil?

(İlkellerden başka ..)

Çünkü yığın tabanlı nesneler yığın tabanlı referanslardan farklı semantiklere sahiptir. Aşağıdaki kodu C ++ 'da hayal edin; bu ne işe yarıyor?

return myObject;

• Eğer myObjectyerel bir yığın tabanlı nesnedir (sonuç şeye atanmışsa), kopyalamaya karşı yapıcı denir.
• Eğer myObjectbir yerel yığın tabanlı nesne ve biz bir başvuru dönen, sonuç tanımsızdır.
• Eğer myObjectbir üye / küresel nesnedir (sonuç şeye atanmışsa), kopyalamaya karşı yapıcı denir.
• Eğer myObjectbir üye / küresel nesne ve biz bir başvuru dönen referans döndürülür.
• Eğer myObjectyerel yığın tabanlı bir nesne için bir gösterici, tanımlanmamış.
• Eğer myObjectbir üye / küresel nesneye bir işaretçi, yani gösterici döner.
• Eğer myObjectbir bellek tabanlı bir nesne için bir gösterici, bu işaretçi döndürülür.

Şimdi aynı kod Java’da ne yapıyor?

return myObject;

• Referans myObjectgeri döndü. Değişkenin yerel, üye veya global olması önemli değil; ve endişelenecek yığın tabanlı nesneler veya işaretçi vakaları yoktur.

Yukarıda, yığın tabanlı nesnelerin neden C ++ 'da programlama hatalarının çok yaygın bir nedeni olduğu gösterilmektedir. Bu nedenle, Java tasarımcıları onları çıkardı; ve onlarsız, Java’da RAII kullanmanın bir anlamı yoktur.

Deliklerini açıklamanız usingeksik. Aşağıdaki sorunu göz önünde bulundurun:

interface Bar {
    ...
}
class Foo : Bar, IDisposable {
    ...
}

Bar b = new Foo();

// Where's the Dispose?

Bence hem RAII hem de GC'ye sahip olmamak kötü bir fikirdi. Java dosyaları kapanış gelince, bu kadar malloc()ve free()orada.

Ben çok yaşlıyım. Orada bulundum ve gördüm ve kafamı çok sık çarptım.

IBM erkeklerinin bize bu yeni Java dilinin ne kadar harika olduğunu anlattıkları Hursley Park'taki bir konferanstaydım, sadece birisi sordu ... neden bu nesneler için bir yıkıcı yok. C ++ 'da yıkıcı olarak bildiğimiz bir şeyi kastetmedi, ancak sonlandırıcı da yoktu (ya da sonlandırıcıları vardı ama temelde işe yaramadı). Bu çok geriye döndü ve Java'nın bu noktada biraz oyuncak dil olduğuna karar verdik.

Şimdi de finalizatörleri dilin teknik özelliklerine eklediler ve Java bazı uyarlamalar gördü.

Tabii ki, daha sonra herkese finalistleri nesnelerine koymadıkları söylendi çünkü GC'yi inanılmaz derecede yavaşlattı. (yalnızca yığını kilitlemekle kalmayıp, sonlandırılacak nesneleri geçici bir alana taşımak zorunda kaldığından, bu yöntemler GC'nin uygulamayı çalıştırmasını duraklattığı için çağrılamaz. Bunun yerine hemen sonraki çağrılırlar. GC döngüsü) (ve daha da kötüsü, uygulama kapatıldığında bazen sonlandırıcı hiçbir zaman hiç aranmaz. Dosya tanıtıcınızın hiç kapalı olmadığını hayal edin)

Sonra C # 'ye sahip olduk ve MSDN'deki tartışma forumunu hatırlıyorum. Birisi neden deterministik bir sonlandırma olmadığını sordu ve MS çocukları bize bu tür şeylere nasıl ihtiyaç duymadığımızı söylediler, sonra bize uygulamalar tasarlama biçimimizi değiştirmemiz gerektiğini söylediler, sonra bize GC'nin ne kadar şaşırtıcı olduğunu ve tüm eski uygulamalarımızın nasıl olduklarını anlattılar Çöp ve tüm dairesel referanslar nedeniyle hiç çalışmadı. Sonra baskıya girdiler ve bu İddialı paterni kullanabileceğimiz şartnameye eklediklerini söylediler. Bu noktada C # uygulamalarında bizim için manuel bellek yönetimine döndüğümüzü sanıyordum.

Tabii ki, MS'li çocuklar daha sonra bize anlattıklarının hepsinin ... iyi olduğunu keşfettiler, IDispose'ı standart bir arayüzden biraz daha fazla yaptılar ve daha sonra use deyimini eklediler. W00t! Deterministik sonlandırmanın sonuçta dilden eksik bir şey olduğunu fark ettiler. Tabii ki, yine de her yere koymayı hatırlamalısın, bu yüzden hala biraz el kitabı, ama daha iyi.

Öyleyse neden baştan beri her bir kapsam bloğuna otomatik olarak stil anlambilgisi yerleştirmiş olurlarsa bunu yaptılar? Muhtemelen verimlilik, ama sadece farkına varmadıklarını düşünmekten hoşlanıyorum. Sonunda olduğu gibi hala NET'te akıllı işaretçilere ihtiyacınız olduğunu anladılar (google SafeHandle) GC'nin gerçekten tüm sorunları çözeceğini düşünüyorlardı. Bir nesnenin sadece bellekten daha fazlası olduğunu ve GC'nin öncelikle bellek yönetimini idare etmek için tasarlandığını unutmuşlardır. GC'nin bunu halledeceği fikrine kapıldılar ve oraya başka şeyler koyduğunuzu unuttular, bir nesne sadece bir süre silmediğiniz önemli olmayan bir bellek bloğu değildir.

Ancak, orijinal Java’daki bir sonlandırma yönteminin olmamasının da bundan biraz daha fazlası olduğunu düşünüyorum - yarattığınız nesnelerin tamamen bellekle ilgisi olduğunu ve başka bir şey silmek istiyorsanız (bir DB tutacağı veya bir soket veya başka bir şey gibi) ) o zaman manuel olarak yapmanız bekleniyordu .

Java'nın, insanların pek çok manuel tahsisatlı C kodu yazmaya alışkın olduğu gömülü ortamlar için tasarlandığını, bu nedenle otomatik olarak özgür olmamanın çok fazla bir sorun olmadığını - daha önce hiç yapmadıklarını, neden Java’ya ihtiyacınız olduğunu hatırlayın. Sorun, iş parçacığı ya da yığın / öbek ile ilgili bir şey değildi, muhtemelen bellek ayırmayı (ve dolayısıyla ayırmayı) biraz daha kolaylaştırmak için oradaydı. Sonuç olarak, try / finally deyimi, bellek dışı kaynakları işlemek için muhtemelen daha iyi bir yerdir.

Yani IMHO, .NET'in basitçe Java'nın en büyük kusurunu kopyalaması en büyük zayıflığı. .NET daha iyi bir C ++ olmalıydı, daha iyi bir Java.

"Java'da Düşünme" ve "C ++ 'da Düşünme" ve C ++ Standartlar Komitesinin bir üyesi olan Bruce Eckel, birçok alanda (sadece RAII değil) Gosling ve Java ekibinin yapmadığını düşünüyor. ev ödevi.

... Dilin hem hoş olmayan hem de karmaşık olabileceğini ve aynı zamanda iyi tasarlandığını anlamak için, C ++ 'da her şeyin askıda kaldığı ana tasarım kararını aklınızda tutmalısınız: C. Stroustrup karar verdi - ve doğru bir şekilde Görünüşe göre C programcı kitlelerinin nesnelere hareket etmesini sağlamanın yolu, hareketi saydamlaştırmaktı: C kodlarını C ++ 'da değiştirmeden derlemelerini sağlamak. Bu muazzam bir kısıtlamadı ve her zaman C ++ 'ın en büyük gücü ... ve dezavantajı olmuştur. C ++ 'ı olduğu kadar başarılı ve olduğu kadar karmaşık yapan şey bu.

Ayrıca C ++ 'ı yeterince iyi anlamayan Java tasarımcılarını kandırdı. Örneğin, operatörlerin aşırı yüklenmesinin programcıların doğru kullanması için çok zor olduğunu düşünüyorlardı. Temel olarak C ++ için doğrudur, çünkü C ++ hem yığın ayırma hem de yığın ayırma işlemine sahiptir ve tüm durumları ele almak ve bellek sızıntısına neden olmamak için operatörleri aşırı yüklemelisiniz. Gerçekten zor. Bununla birlikte, Java, C # 'da gösterildiği gibi (ancak Java'dan önce Python'da gösterilmişti) operatörün aşırı derecede aşırı yüklenmesine neden olan tek bir depolama ayırma mekanizmasına ve bir çöp toplayıcısına sahiptir. Ancak uzun yıllar boyunca, Java ekibinden gelen kısmen “Operatör aşırı yüklemesi çok karmaşık” tır. Bu ve birçoğunun açıkça yapmadığı birçok karar

Başka pek çok örnek var. İlkel "verimlilik için dahil edilmek zorundaydı." Doğru cevap, "her şey bir nesnedir" dürüst olmak ve verimlilik gerektiğinde daha düşük seviyeli faaliyetler yapmak için bir tuzak kapısı sağlamaktır (bu, sıcak nokta teknolojilerinin işleri daha şeffaf hale getirmelerine olanak tanıyacaktı. Sahip olmak). Ve kayan nokta işlemciyi aşkın işlevleri hesaplamak için doğrudan kullanamamanız gerçeği (bunun yerine yazılımda yapılır). Elimden geldiğince bu tür konular hakkında yazdım ve duyduğum cevap her zaman "Java yolu bu" etkisine ilişkin bazı totolojik cevaplar oldu.

Jeneriklerin ne kadar kötü bir şekilde tasarlandıklarını yazdığımda, aynı cevabı aldım, "Java'da verilen önceki (kötü) kararlarla geriye dönük olarak uyumlu olmalıyız". Son zamanlarda gittikçe daha fazla sayıda insan Generics ile kullanımlarının gerçekten çok zor olduğunu görmek için yeterli deneyime sahip oldu - gerçekten, C ++ şablonları çok daha güçlü ve tutarlı (ve derleyici hata mesajlarının tolere edilebildiği için artık kullanımı çok daha kolay). İnsanlar yeniden birleşmeyi bile ciddiye alıyorlardı - faydalı olacak ancak kendisinin empoze ettiği kısıtlamalar tarafından saklanan bir tasarımda bu kadar fazla diş açmayacak bir şey.

Liste çok sıkıcı olduğu noktaya gidiyor ...

En iyi neden, buradaki cevapların çoğundan daha basittir.

Yığın ayrılmış nesneleri diğer iş parçacıklarına iletemezsiniz.

Dur ve bunu düşün. Düşünmeye devam et .... Şimdi C ++ 'da herkes RAII' de bu kadar keskinleştiği zaman konu yoktu. Erlang bile (diş başına ayrı yığınlar), etrafta çok fazla nesne geçtiğinde cimri olur. C ++ yalnızca C ++ 2011'de bir bellek modeline sahipti; Şimdi derleyicinizin "belgelerine" başvurmak zorunda kalmadan C ++ 'daki eşzamanlılık hakkında neredeyse neden olabilirsiniz.

Java (neredeyse) günden itibaren birden fazla konu için tasarlanmıştır.

Stroustrup'un bana konuya ihtiyacım olmayacağına dair garanti verdiği eski "C ++ Programlama Dili" nin eski kopyasını aldım.

İkinci acı sebep dilimlemekten kaçınmak.

C ++ 'ta, daha yüksek seviyeli bir tane (RAII) uygulamak için daha genel amaçlı, daha düşük seviyeli dil özellikleri (yığın tabanlı nesnelerde otomatik olarak çağrılan yıkıcılar) kullanırsınız ve bu yaklaşım C # / Java milletinin görünmediği bir şeydir. çok düşkünüm. Özel ihtiyaçlar için özel üst düzey araçlar tasarlamayı ve dilleri hazırlamış programcılara sunmayı tercih ediyorlardı. Bu tür özel araçlarla ilgili sorun, kişiselleştirilmelerinin çoğu zaman imkansız olmalarıdır (kısmen öğrenmelerini kolaylaştıran şey budur). Küçük bloklardan inşa ederken, zaman içinde daha iyi bir çözüm ortaya çıkabilir, ancak yalnızca yüksek seviyeli yerleşik yapılara sahipseniz , bu daha az olasıdır.

Yani evet, sanırım (aslında orada değildim ...) dillerin daha kolay anlaşılmasını sağlamak amacıyla bilinçli bir karardı, ama bence kötü bir karardı. Sonra tekrar, genellikle C ++ 'ın programcılarına kendi felsefelerini alma şansını vermelerini tercih ediyorum, bu yüzden biraz önyargılıyım.

Zaten buna benzer kaba bir eşdeğerini C # Disposeyöntemiyle çağırdınız . Java da vardır finalize. NOT: Java'nın sonlandırmasının deterministik ve farklı olduğunu fark Disposeettim, sadece ikisinin de GC ile birlikte bir temizlik yöntemine sahip olduğuna işaret ediyorum.

Eğer bir şey C ++ daha fazla acı çekerse, bir nesnenin fiziksel olarak imha edilmesi gerekir. C # ve Java gibi daha yüksek seviyelerde, artık referans olmadığında temizlemek için bir çöp toplayıcısına güveniyoruz. C ++ 'daki DBConnection nesnesinin hileli referansları ya da işaretçileri olmadığının garantisi yoktur.

Evet, C ++ kodunu okumak daha sezgisel olabilir, ancak hata ayıklamak için bir kabus olabilir çünkü Java gibi dillerin yerine getirdiği sınırlar ve sınırlamalar, diğer geliştiricilerin ortak çaylak hatalarından korunmasının yanı sıra daha ağırlaştırıcı ve zor hatalardan bazılarını da ortadan kaldırır.

Belki bazıları C + 'nın düşük seviyeli gücü, kontrolü ve saflığı gibi tercihlerimden kaynaklanmaktadır, ki burada benim gibi diğerleri daha açık olan daha sandboxed bir dili tercih etmektedir.