Son zamanlarda C# 4.0 ile birlike gelen yeniliklerden haberdarız. Geçmişteki yeniliklerden belkide en önemli olanı, CLR(Common Language Runtime) çekirdiğinde değiştirilme yapılmasını da zorunlu kılan generic mimariydi. Tabiki generic dışında gelen, yield anahtar kelimesi, isimsiz metodlar(anonymous methods), static sınıflar ve diğerleride önemli gelişmelerdi. Zaman ilerledi ve C# 3.0 ile birlikte bu kez hayatımıza, generic modelinden daha fazla etki yapan LINQ(Language INtegrated Query) girdi. Bir geliştirici olarak her zaman için yeniliklere açık olmamız ve yakalayabildiğimiz ölçüde takip etmemiz gerektiğini düşünüyorum. Bu bir geliştirici için neredeyse bir yaşam tarzı. Dolayısıyla artık C# 4.0 üzerinde konuşmanın zamanı geldide geçiyor.

C# 4.0 ile birlikte gelen yeniliklerin daha çok dinamik çalışma zamanını(Dynamic Language Runtime-DLR) kullanan diller üzerinde odaklanmış durumda olduğunu söyleyebiliriz. Peki bu ne anlama geliyor? DLR tarafını ilgilendiren dillere ait nesneler ile daha kolay konuşulması olarak küçük bir sebep belirtebiliriz. Bu nedenle C# 4.0 ile birlikte gelen önemli yeniliklerden birisi olan dynamic anahtar kelimesi sayesinde, Python, Ruby veya Javascript ile üretilen nesnelerin C# 4.0 tarafında late-binding ile ele alınması mümkün. Hatta var olan .Net nesnelerinin reflection kullanılmadan ele alınması veya COM objelerine ait üyelerin çağırılmasında bu anahtar kelimeyi kullanabiliyoruz. Aslında C#’ ın 2.0, 3.0 versiyonunda gelen yenilikler nasıl ki belirli ihtiyaçlar nedeni ile ortaya çıkmışsa, C# 4.0 ile gelen yenilikleride bu anlamda düşünmemiz ve araştırmamız gerekiyor.
B.S.Ş.

Garbage Collection değişiklikleri

CLR 4.0 ile beraber Garbage Collection tarafında iyileştirmeler yapılmış. Performans konusunda yapılan bu iyileştirmeler ile GC’nin çalışma algoritmalarında büyük değişiklikler var. .NET Framework tarafında yaratılan objeler belli koleksiyonlarda tutuluyor. Objeler yaşam sürelerine göre bu koleksiyonlar da konumlanıyor. GC’da bu koleksiyonlardaki objeleri yaşam sürelerine göre topluyor,yok ediyor…CLR 4.0’da bu işler artık daha hızlı.

İç içe çalışan CLR

CLR 4.0’ın bence en güzel yeniliklerinden biri de, içerisinde başka CLR versiyonlarının da çalışabilmesi. Ne demek oluyor bu açalım biraz daha…. .NET Framework ile çalışan ana uygulama tek bir CLR versiyonu yükleyebiliyordu. Bu da uygulamalarda destek sorununa neden olabiliyordu. Mesela CLR 1.0 versiyonu ile çalışan bir uygulamaya, CLR 2.0 versiyonu ile bir şey yazamıyorduk. CLR 4.0 ile artık bu sorun ortadan kalkıyor.

Yakalanamayan hatalar
Önceki CLR versiyonlarında bazı unmanaged işlemlerden doğan hataları yakalamak normal try-catch blokları ile mümkün değildi. InvalidMemory,AccessViolation falan filan gibi. CLR 4.0 ile artık bu tarz hataları yakalamak daha kolay. Bunun için [HandleProcessCorruptedStateExceptions] özelliğini programımızın başlangıcına eklememiz yeterli.

Profiling yenilikleri

Uygulamaları profile etmek için önceki CLR versiyonlarında üretim ortamına Visual Studio kurmamız gerekmekteydi. Artık buna gerek yok…

Dump Debuging

Belli arayüzler ile artık uygulamalarımızda dump debuging yapabileceğiniz. Hata olduğunda “Gönderim mi,göndermiyim mi” sorusu ile başbaşa kaldığımız ekran .NET 4.0 ile kendi uygulamalarımız adına biraz daha anlam kazanacak.

Çok çekirdekli .NET

Ay çekirdeği tadındaki bu en güzel yenilik, artık çok çekirdekli işlemcilerde, bu çekirdeklerden faydalanmamızı sağlayacak Parallel Extensions olarak karşımıza çıkıyor. CLR thread’leri artık bu çekirdekler arasında dağıtılabilinecek.

Kod kontratları

AOP kavramı, Code Contracts kavramı ile CLR 4.0’da .NET 4.0’ın daha bir içine giriyor. Artık .NET 4.0’da methodlarımıza belli condition’ları belirterek, runtime sırasında nasıl çalışacağını belirtebiliyoruz. Bu aynı zamanda kodlarımızın compile sırasında farklı şekilde derlenebilmesini ve farklı ortamlarda çalışabilmesini sağlıyor olacak. Bir uygulamanın Windows, XBOX ve Windows Phone üzerinde değişmeden çalışmasının temelinde bu olay yatıyor işte…

A.Ç.