C/C++ C++ öğreniyorum gün 2

C/C++ çok zor bir dil. Birgün niyetlendim de pointer falan varmış Ram'deki verinin adresini gösteriyormuş, birde framework falan yoksa kodu kendin optimize ediyormuşun. Mesela çöp toplayıcı mekanizması doğrudan yokmuş.
Haklısınız, gui'nin formunu hazırlamak bile kafa karıştırıcı ve 1 günden fazla sürüyor, bilgisayarları anlamak zor iş.
 
Fabrikada çalışıyordum, makinelerin ekranında böyle formlar vardı. Demek C++ ile yazmışlar.
Tabiki genel olarak mantıksal ve data içeren formlar C++ ile yazılır, tasarım ve lokal uygulamalar C# ile yazılır.
 
C/C++ çok zor bir dil. Birgün niyetlendim de pointer falan varmış Ram'deki verinin adresini gösteriyormuş, birde framework falan yoksa kodu kendin optimize ediyormuşun. Mesela çöp toplayıcı mekanizması doğrudan yokmuş.
C++'a özel bir şey değil pointerlar. Optimizasyon durumu da. Ama evet, dediğin gibi.

GC olmaması durumu zorlaştıran bir şey değil. Scope takip etmeyi biliyorsan, GC olmaması ciddi bir problem teşkil etmiyor.

C++ objeleri scope dışına çıktığında ölürler. (Yine C++ özel bir durum değil) Yaşamazlar. Pointerlar bu duruma istisna tabii ki. Onların life timelarını biz yönetiyoruz. C++'ta constructorlar gibi, destructorlar da var. Bunlar objenin scope bitişinde yok olmasını sağlayan şeyler. Varsayılan olarak C++ compilerları senin için default, copy, move constructor ve destructor'ı oluşturacak. Bunlarla da memory management yapıyorsun.

Mesela kopyalanmasını istemediğimiz şeyler var. Pointer memberı olan şeyleri kopyalamak istemeyebilirsin mesela. Aşırı large dataların kopyalanmamasını isteyebilirsin. Sadece move edilmesini istersin mesela. Bu tarz durumlarda memory managementi kendin yapıyor olmak daha sağlıklı oluyor. Ne yaptığını bilerek iş yapmış oluyorsun. Her GC çağrısında da performans hiti yemiyorsun mesela.

Program yaşadığı müddetçe hayatta kalmasını istediğimiz datalarda var. Mesela kullandığım game engine de Bitmap dataları ekrana çizdirmeye devam edebilmem için OpenGL'e gerçekleşen context share süresince Bitmap'ın datasının hayatta kalması ve silinmemesi lazım ki OpenGL çizmeye devam edebilsin. Aksi halde OpenGL datayı bulamayacağı için çizemeyecek ve çökecek.

GC'ler genelde bunları otomatik takip eder ve nadiren başarısız olurlar takip sırasında. Fakat bu takip süreci performansa etki ediyor işte.
 
C++'a özel bir şey değil pointerlar. Optimizasyon durumu da. Ama evet, dediğin gibi.

GC olmaması durumu zorlaştıran bir şey değil. Scope takip etmeyi biliyorsan, GC olmaması ciddi bir problem teşkil etmiyor.

C++ objeleri scope dışına çıktığında ölürler. (Yine C++ özel bir durum değil) Yaşamazlar. Pointerlar bu duruma istisna tabii ki. Onların life timelarını biz yönetiyoruz. C++'ta constructorlar gibi, destructorlar da var. Bunlar objenin scope bitişinde yok olmasını sağlayan şeyler. Varsayılan olarak C++ compilerları senin için default, copy, move constructor ve destructor'ı oluşturacak. Bunlarla da memory management yapıyorsun.

Mesela kopyalanmasını istemediğimiz şeyler var. Pointer memberı olan şeyleri kopyalamak istemeyebilirsin mesela. Aşırı large dataların kopyalanmamasını isteyebilirsin. Sadece move edilmesini istersin mesela. Bu tarz durumlarda memory managementi kendin yapıyor olmak daha sağlıklı oluyor. Ne yaptığını bilerek iş yapmış oluyorsun. Her GC çağrısında da performans hiti yemiyorsun mesela.

Program yaşadığı müddetçe hayatta kalmasını istediğimiz datalarda var. Mesela kullandığım game engine de Bitmap dataları ekrana çizdirmeye devam edebilmem için OpenGL'e gerçekleşen context share süresince Bitmap'ın datasının hayatta kalması ve silinmemesi lazım ki OpenGL çizmeye devam edebilsin. Aksi halde OpenGL datayı bulamayacağı için çizemeyecek ve çökecek.

GC'ler genelde bunları otomatik takip eder ve nadiren başarısız olurlar takip sırasında. Fakat bu takip süreci performansa etki ediyor işte.
Hocam tam olarak nasıl bir veri olduğunu bilmediğim için bir şey diyemiyorum ama null olmadığı sürece GB direkt devreye girmiyor öyle.

Birde mesela LibGDX'de OpenGL sürekli çiziyor Render metodunda. Buradaki olayları bilmiyorum, belki sürekli bir şey new'leniyordu yada aktarılıyordur.

Birde bazı işaretler var Java'da mesela büyük veriyi direkt çekmiyor @Lazy anahtarı.

Direkt temeli kontrol etmesek de böyle programı yönlendirebilediğimiz işaretler oluyor. Ben zaten işaretleri kullanıyorum direkt. Lombok işaretler, Spring işaretleri. Çok yardımcı oluyor. Programın kontrolünü Spring'e devrediyorum.
 
Hocam tam olarak nasıl bir veri olduğunu bilmediğim için bir şey diyemiyorum ama null olmadığı sürece GB direkt devreye girmiyor öyle.
GC null olmasını beklemek zorunda değil. Dataya referans kaybolduysa devreye girer. Kullanan yoksa temizler datayı.

GC'nin yanlış takip etmez genelde. Ancak takibin kendisi başlı başına performansa etkisi olan bir şey. Garbage collected dillerin en hızlısı Java bile C++'tan yavaş çalışacak, hemde minimum %30-40 gibi bir performans kaybından bahsediyoruz.

Java memory management için muazzam şeyler yapıyor. Tartışmasız. Ancak bu memory management'ın otomasyonu, daha önce de bahsettiğim gibi performansta düşmelere sebep oluyor.

Ek olarak GC her zaman ihtiyaç duyduğumuz bir şey değil. Daha güvenli bir yaklaşım mı? Evet. Rapid development dediğimiz, aşırı hızlı geliştirme yapılan uygulamalarda, GC'ye sahip olmak daha az bellekle alakalı bug ile program yazmana olanak sağlıyor. Fakat şart değil. C++'ta eğer belirli ilkelere uyarsan, zaten GC'nin yaptığı her şey otomatik olarak gerçekleşiyor çünkü dilin dizaynı böyle.

Örneğin sadece datasını kullanacağın bir değişkeni const ref olarak alırsan, kopyalamadan kaçınmış olursun. Eğer kendi üstünde değişiklik yapman gerekiyorsa ama nesnenin orijinalini bozmak istemiyorsan kopyalarsın. Referans aldığın nesneler sana ödünç verilmiştir, işin bittiğinde sahiplerine senin üzerlerinde yaptığın değişiklikler ile birlikte geri dönerler.

Kısaca anlatmaya çalıştığım şey GC'nin şart olmadığı ve olmamasının ciddi bir problem teşkil etmediği. Hatta belirli durumlarda olmamasının daha hayırlı olduğu. Tamamen projenin ve ürünün gereksinimlerine göre karar verdiğimiz bir şey.
 

Technopat Haberler

Yeni konular

Geri
Yukarı