Rust dilindeki ownership sistemi nasıl işliyor?

30 Haz 02:22

Rust'ın ownership sistemiyle C++'daki smart pointer'ları karşılaştırırsak olay daha net anlaşılır kanka. C++'ta `unique_ptr` ya da `shared_ptr` kullanarak bellek yönetimini hallederiz, Rust'ta bu otomatikleşmiş ama kuralları katı. Owner olmadan bir değişkenin boşta gezmesi imkansız, tıpkı `unique_ptr`'daki sahiplik gibi. Borrow checker da zaten bu sahiplik kurallarını derleme zamanında çözüyor. Mesela bir `String`'in owner'ı varsa, referans almaya çalıştığında (borrow) sadece ya okunabilir ya da değiştirilebilir şekilde verebiliyorsun, ikisi birden olmuyor. Move semantics'e gelince, bence bu C++ move semantics'in rust versiyonu ama daha da katı. Mesela `let s = String::from("merhaba"); let s2 = s;` yaptığında `s`'in owner'ı değişiyor, yani `s` artık kullanılabilir değil. Copy trait devreyeyse işler değişiyor. Basit tipler (`i32`, `bool` vs.) otomatik olarak Copy trait'i implement ediyorlar, yani onlar kopyalanabiliyor. `let x = 5; let y = x;` dediğinde aslında `x` ve `y` birbirinden bağımsız oluyor. Ama `String` gibi heap üzerinde yer kaplayan tipler için Copy varsayılan olarak yok, Move kullanmak zorundasın.

30 Haz 02:46

Geçen ay Rust'a dalmaya çalışırken ben de senin gibi ownership denen şey yüzünden epey kafayı yemeye başlamıştım kanka. İlk başta "neden bu kadar karışık bir sistem var?" diyordum, çünkü C++'tan geliyordum ve pointerlar, referanslar derken zaten kafam karışıktı. Sonra arkadaşımın uyarısıyla bir basit kod parçasıyla denemeye başladım: ```rust fn main() { let s = String::from("merhaba"); takes_ownership(s); // burda s artık ownersiz kalıyor // println!("{}", s); // derleme hatası! } fn takes_ownership(some_string: String) { println!("{}", some_string); } // some_string burda ölüyor ve memory otomatik temizleniyor ``` Valla bu kodu yazdıktan sonra "hocam ne oluyor?" dedim. Sonra borow checker'ın aslında ne kadar akıllı olduğunu anladım - elinde s değişkeni varken onu bir fonksiyona geçirdiğimde, derleyici "abi sen burda artık s'yi kullanamazsın" diye haykırıyordu. Bu sayede memory leak ya da double free problemi otomatikman önlüyordu. Move semantics denen şey de işte tam bu: bir verinin ownership'ini başka bir değişkene devrediyorsun, eski owner artık onu kullanamıyor. Copy trait konusu da enteresan - basit tipler (i32, bool gibi) için Rust otomatik olarak Copy implement eder, yani sahibini kaybetmeden fonksiyona geçirebilirsin. Ama String gibi heap bellek kullanan tipler Copy olmaz, onlara sahip olunduğunda move semantics devreye girer. Ben ilk kez bunu anladığımda "ahh demek mantık buymuş!" diye sevinmiştim. Bence sen de bu basit örneği çalıştır, derleyicinin verdiği hataları incele - o hata mesajları borow checker'ın ne kadar yardımsever olduğunu gösterecek.

30 Haz 03:07

Seninle tıpkı bir usta marangozun elindeki ahşabı nasıl dikkatle ölçtüğünü anlatıyorum kanka, Rust da kodunu öyle. Borrow checker, tıpkı marangozun elindeki testereyi sürekli ölçüp "bu en fazla 3 cm girer, yoksa tahta çatlar" mantığı gibi çalışıyor. Yani değişkenler ya sahibi (owner) oluyor, ya geçici olarak ödünç alınmış (borrowed) ya da hareket ettirilmiş (moved) oluyor. Move semantics de kodundaki değişkeni tıpkı bir emaneti elinden bırakıp başka birine vermek gibi; eski değişken artık kullanılamaz hale geliyor. Copy trait ise basit verilerde (integers, bool, small structlar) devreye girip "ben kopyayım, sorun yok" diyor, tıpkı bir kağıdı fotokopi makinesinde çoğaltmak gibi. Basit örnek: ```rust let s = String::from("merhaba"); // s sahibi (owner) let s2 = s; // s artık kullanılmaz, move edilmiş // println!("{}", s); // hata verir let x = 5; // sayısal, Copy trait'li let y = x; println!("{} {}", x, y); // ikisi de çalışır ``` Görüldüğü gibi String'de move oluyor, basit sayılarda copy. Borrow checker da tam burada devreye girip "bu taşıma kuralını ihlal etme" diyor.