C/C++'tan Geçiş
Kavram eşlemesi ve tuzaklar

00 Zihniyet değişimi

Rust'ı C++ gibi yazmaya çalışırsan derleyici sürekli yolunu keser; doğru hamle borrow checker'ı bir düşman değil, bir tasarım ortağı olarak görmektir.

C/C++ dünyasından gelen herkesin ilk haftalarda yaşadığı duygu aynıdır: derleyiciyle güreşmek. Kafandaki algoritma nettir, C'de beş dakikada yazardın, ama Rust derleyicisi borrow of moved value, cannot borrow as mutable, does not live long enough diye art arda reddediyor. Bu noktada iki yol var: ya hataları susturmak için rastgele .clone(), Rc<RefCell> ve unsafe serpiştirirsin, ya da derleyicinin sana ne söylemeye çalıştığını dinlersin. İkinci yol acı verir ama tek doğru yoldur.

Zihniyet farkını tek cümleyle özetlemek gerekirse: C++'ta kod yazarken belleği düşünürsün; Rust'ta tasarım yaparken sahipliği düşünürsün. C++'ta bir nesneyi kim siler, kim sahiplenir, kim sadece bakar — bunları kafanda ya da yorum satırlarında tutarsın ve hata yaptığında runtime'da öğrenirsin. Rust'ta aynı soruların cevabını tip imzasına yazarsın: fn f(x: T) sahipliği alır, fn f(x: &T) ödünç bakar, fn f(x: &mut T) ödünç değiştirir. İmza bir sözleşmedir ve derleyici onu zorlar.

C++ refleksi              Rust yaklaşımı
─────────────             ─────────────
kodu yaz → derle →        sahipliği tasarla →
crash'i debug et          derleyici doğrular → çalışır

Borrow checker'ı bir linter ya da bir hata bulucu sanmak en yaygın yanılgıdır. O bir doğrulayıcıdır: sen veri akışını ve ömürleri doğru tasarladıysan onaylar, tasarlamadıysan reddeder. Yani borrow checker hatası genelde "şu satırı düzelt" değil, "bu verinin sahibi kim olmalı, ömrü neye bağlı olmalı" sorusunu yeniden sormanı söyler. Deneyimli Rust geliştiricileri bu yüzden borrow checker'la neredeyse hiç güreşmez — çünkü kodu yazmadan önce sahipliği kafalarında çözmüşlerdir.

01 Büyük kavram eşleme tablosu

Çoğu C/C++ kavramının Rust'ta doğrudan bir karşılığı vardır; ama eşleme birebir değil — bazı kavramlar tek bir Rust özelliğine, bazıları ise dile içkin bir varsayılana karşılık gelir.

Aşağıdaki tablo bu rehberin omurgasıdır. Bir kavramı ararken buraya dön; her satır sonraki bölümlerde ya da ilgili rehberlerde derinleştirilir. Önemli olan nüansı görmek: bazı C++ kavramları (örn. const, kopya semantiği) Rust'ta artık varsayılan davranış olduğu için "özel bir özellik" olmaktan çıkmıştır.

İki satır özellikle dikkat ister. NULL → Option: Rust'ta "bir değer olmayabilir" durumu tipte kodlanır, dolayısıyla null pointer dereference diye bir hata kategorisi yoktur. const → varsayılan immutable: C++'ta değişkenleri korumak için const eklersin; Rust'ta tam tersi — her şey değişmezdir, değiştirmek istediğinde mut eklersin. Bu tek kelimelik tersine çevirme, kodun büyük kısmını otomatik olarak daha güvenli yapar.

02 Bellek modeli farkı

C++'ta atama varsayılan olarak kopyalar (kopya ctor), Rust'ta atama varsayılan olarak taşır (move) — bu tek fark birçok refleksini tersine çevirir.

C++'ta bir nesneyi başka bir değişkene atadığında, aksini belirtmedikçe kopya yapıcı (copy constructor) çağrılır. Büyük bir vektörü farkında olmadan kopyalamak, C++'ta klasik performans tuzağıdır; bu yüzden std::move ve referansları öğrenirsin. Rust'ta varsayılan tersidir: atama taşır (move), kopyalamaz. Taşınan değer artık kullanılamaz — eski sahip "boşaltılır".

// C++: atama varsayılan olarak KOPYALAR
std::vector<int> a = {1, 2, 3};
std::vector<int> b = a;   // derin kopya — a hâlâ geçerli, sessiz maliyet
a.push_back(4);           // b etkilenmez

// Rust: atama varsayılan olarak TAŞIR (move)
let a = vec![1, 2, 3];
let b = a;        // sahiplik b'ye taşındı — kopya YOK
// a.push(4);     // HATA: borrow of moved value: `a`
let c = b.clone(); // kopya istiyorsan AÇIKÇA söyle

Buradaki kazanım şudur: Rust'ta hiçbir derin kopya sessizce oluşmaz. Kopyalamak istiyorsan .clone() yazarsın ve maliyet kodda görünür hale gelir. i32, bool, char gibi küçük, sabit boyutlu tipler Copy trait'ini uygular ve gerçekten kopyalanır — ama bunlar bit kopyası olduğu için ucuzdur. Heap tutan her şey (String, Vec, Box) move semantiğindedir.

RAII tarafında Rust C++'tan daha katıdır ve daha rahattır. C++'ta destructor'ı elle yazarsın ve "rule of three/five" gibi kuralları akılda tutarsın. Rust'ta Drop derleyici tarafından üretilir: bir değer kapsamdan çıktığında alanları otomatik olarak, tanımlanma sırasının tersinde drop edilir. Özel temizlik gerekirse impl Drop yazarsın — ama Drop uygulayan bir tip artık Copy olamaz, çünkü "iki kopya, iki temizlik" çelişkisi olurdu.

03 Sık refleks tuzakları — bellek/erişim

C'deki en sağlam alışkanlıkların bir kısmı Rust'ta ya gereksizdir ya da doğrudan borrow checker'a çarpar; bunları erken fark etmek aylarca zaman kazandırır.

İlk tuzak: index'li manuel döngü. C'de for (int i = 0; i < n; i++) refleksi kasına işlemiştir. Rust'ta bu hem deyimsiz (idiomatic değil) hem de bound-check maliyetli kalır. Iterator kullan — derleyici sınır kontrolünü çoğunlukla eler ve kod daha okunur olur.

// C++ refleksi: index'li manuel döngü
std::vector<int> v = {1, 2, 3};
int sum = 0;
for (size_t i = 0; i < v.size(); i++)
    sum += v[i];   // her erişimde manuel index

// Rust deyimi: iterator
let v = vec![1, 2, 3];
let sum: i32 = v.iter().sum();       // niyet net, sınır kontrolü elenir
// ya da: for x in &v { ... }

İkinci tuzak: paylaşımlı değiştirilebilir erişim. C'de iki pointer aynı tampona yazabilir; bu da aliasing bug'larının kaynağıdır. Rust'ın kuralı kemik gibi sağlam: aynı anda ya çok sayıda &T (salt-okunur) ya da tek bir &mut T (değiştirilebilir) olabilir — ikisi bir arada olamaz. Bu yüzden C'de doğal gelen "elimde iterator varken aynı koleksiyonu değiştireyim" hamlesi Rust'ta derlenmez (ve iyi ki derlenmez — C++'ta iterator invalidation tam olarak budur).

Üçüncü tuzak: getter/setter refleksi. C++'ta her alana get_x()/set_x() yazmak yaygındır. Rust'ta alanları doğrudan açmak (pub) ya da değişmez yapı + builder kullanmak çoğu zaman daha deyimseldir; getter/setter sadece gerçekten invariant koruman gerektiğinde yazılır. Encapsulation modül seviyesinde de sağlanır.

Dördüncü tuzak: "yokluk için ham pointer arama". C'de "bulunamadı"yı NULL döndürerek anlatırsın. Rust'ta bu Option<&T>'dir; null kontrolünü unutamazsın çünkü Option'ı açmadan içindeki değere erişemezsin.

04 Araç ve build eşlemesi

Rust'ın en büyük günlük konforu entegre araç zinciridir: build, bağımlılık, test, formatlama ve lint tek bir komutun (cargo) altında toplanır.

C/C++'ta build sistemi seçmek başlı başına bir projedir: Makefile mi, CMake mi, Meson mi; bağımlılıkları nasıl çekeceğin (vcpkg, Conan, submodule) ayrı bir tartışma. Rust'ta bunların hepsi cargo ve Cargo.toml ile gelir. Bağımlılık eklemek tek satırdır, build/test/çalıştırma tek komuttur. Bu, geçişte hissedeceğin ilk somut rahatlamadır.

Günlük döngüde en çok dokunacağın iki araç: cargo clippy ve cargo fmt. Clippy sadece bug değil, deyim de öğretir — "burada iter().sum() kullan", "bu match aslında if let olabilir" gibi öneriler verir. Geçiş döneminde clippy'yi sürekli çalıştırmak, C++ reflekslerini Rust deyimlerine çevirmenin en hızlı yoludur.

cargo fmt → cargo clippy → cargo test → cargo build --release

05 Anti-pattern'ler ve deyimler

"C'de böyle yapardım" cümlesi geçiş sürecinin en tehlikeli cümlesidir; her C kalıbının Rust'ta daha temiz, daha güvenli bir deyimsel karşılığı vardır.

İlk anti-pattern: çıkış parametresi (output parameter). C'de bir fonksiyon hem başarı durumunu hem sonucu döndüremez, bu yüzden sonucu pointer ile dışarı yazarsın. Rust'ta birden çok değer döndürmek serbesttir — tuple ya da daha iyisi Result kullan.

// C: çıkış parametresi + hata kodu
int parse(const char *s, int *out) {
    if (!valid(s)) return -1;   // hata kodu
    *out = atoi(s);               // sonuç dışarı yazılır
    return 0;
}

// Rust: sonuç ve hata tek dönüş değerinde
fn parse(s: &str) -> Result<i32, ParseError> {
    if !valid(s) {
        return Err(ParseError::Invalid);
    }
    Ok(s.parse()?)   // başarı da hata da tipte görünür
}

İkinci anti-pattern: OOP kalıtım hiyerarşisi. C++'ta davranış paylaşmak için temel sınıftan türetirsin. Rust'ta kalıtım yoktur; davranışı trait ile soyutlar, kodu kompozisyonla paylaşırsın. Bu başta kısıtlayıcı gelir ama "elmas kalıtım", "kırılgan temel sınıf" gibi C++ dertlerini tamamen ortadan kaldırır.

C++ kalıtım                Rust kompozisyon
─────────                  ──────────────
Base → Derived             trait Davranış  +  struct { alanlar }
(is-a, sıkı bağ)           (has-a / does, gevşek bağ)

Üçüncü anti-pattern: paylaşımlı değiştirilebilir global. C'de global bir değişkeni her yerden okuyup yazmak yaygındır. Rust'ta değiştirilebilir global (static mut) unsafe'tir ve istenmez. Deyim: durumu parametre olarak geçir, ya da gerçekten global lazımsa OnceLock / LazyLock ile bir kez ilklenen, paylaşımlı (mümkünse immutable) bir değer kullan.

Dördüncü anti-pattern: void*. C'de tip silmek için void* taşır, sonra cast edersin — derleyici seni hiç korumaz. Rust'ta iki temiz alternatif var: tip parametresi gerçekten serbestse generic kullan; sonlu bir tip kümesi taşıyorsan enum kullan. Gerçekten heterojen koleksiyon lazımsa Box<dyn Trait> ile tip güvenli dinamik dağıtım yaparsın.

06 String dünyası

C/C++'ta char* ve std::string karmaşası Rust'ta net bir ikiliye oturur: sahipli String ve ödünç &str — ama UTF-8 ve FFI sınırında birkaç kuzen daha vardır.

C'de string'ler null-terminated char*'tır ve uzunluk, kodlama, sahiplik hep belirsizdir. C++ std::string sahipliği netleştirir ama hâlâ baytlar üzerinde çalışır. Rust string'leri iki temel tipte düşünür ve bu ayrım sahiplikle birebir örtüşür: String sahipli, büyüyebilir, heap'tedir (std::string gibi); &str ise bir string'in ödünç alınmış, değişmez bir dilimidir (bir const char* + uzunluk gibi, ama güvenli).

En kritik kural: fonksiyon parametresi her zaman &str olmalı, String değil. Çünkü &str hem bir String'i hem bir literal'i hem de bir dilimi kabul eder (deref coercion sayesinde), &String ise yalnızca String'i. Sahipliğe gerçekten ihtiyacın yoksa &str al.

// C++: const ref alarak gereksiz kopyadan kaçın
void selam(const std::string& ad) {
    std::cout << "Merhaba " << ad;
}

// Rust: &str al — String, literal ve dilim hepsi geçer
fn selam(ad: &str) {
    println!("Merhaba {ad}");
}
selam("Ada");                 // literal
selam(&String::from("Ada")); // String → &str (otomatik)

İkinci kritik fark: Rust string'leri UTF-8'dir, baytlar değil. Bu yüzden C'deki s[i] ile karakter indekslemek Rust'ta yoktur — çünkü bir "karakter" birden çok bayt olabilir. Bayt gezmek için .bytes(), Unicode skaler değer için .chars() kullanırsın. Bu başta sürpriz olur ama seni gizli kodlama bug'larından korur.

07 Hata yönetimi zihniyeti

Rust'ta hata bir kontrol akışı kaçışı değil, bir değerdir; Result ve ? operatörü exception'ın okunabilirliğini, dönüş kodunun açıklığıyla birleştirir.

C'de hatalar dönüş koduyla (-1, errno) yayılır — açık ama gürültülü, ve kontrol etmeyi unutmak kolaydır. C++'ta exception'lar kodu temizler ama görünmez kontrol akışı yaratır: bir fonksiyonun fırlatıp fırlatmayacağını imzasından anlayamazsın. Rust üçüncü yolu seçer: hata bir değerdir (Result<T, E>) ve tip imzasında görünür, ama ? operatörü onu exception kadar zahmetsiz yayar.

// C++: görünmez kontrol akışı — imza fırlatabileceğini söylemez
Config yukle(const std::string& yol) {
    auto ham = dosya_oku(yol);   // throw edebilir
    return ayristir(ham);         // bu da throw edebilir
}

// Rust: hata imzada görünür, ? ile zahmetsiz yayılır
fn yukle(yol: &str) -> Result<Config, Error> {
    let ham = dosya_oku(yol)?;  // hata varsa erken döner
    let cfg = ayristir(&ham)?;  // zincir devam eder
    Ok(cfg)
}

En önemli zihinsel düzeltme: panic! bir exception DEĞİLDİR. C++'ta exception'lar normal, beklenen hata akışıdır ve yakalanır. Rust'ta panic! "programcı hatası / kurtarılamaz durum" anlamına gelir; varsayılan olarak thread'i sonlandırır ve genelde yakalamak için yazılmaz. Beklenen hatalar (dosya yok, geçersiz girdi, ağ kesildi) her zaman Result ile ifade edilir. panic!'i bir try/catch mekanizması gibi kullanmak Rust'ta anti-pattern'dir.

08 Eşzamanlılık zihniyeti

C/C++'ta eşzamanlılık "paylaş ve kilitle"dir; Rust'ta öncelik "sahiplik + mesajlaş"tır ve veri yarışları derleme zamanında imkânsızdır.

C/C++'ta çok thread'li kod yazmak, doğruluğu tamamen programcının disiplinine bırakan bir mayın tarlasıdır: hangi mutex hangi veriyi korur, kilit sırası nedir, bir alanı kilitsiz okumak güvenli mi? Bu soruların cevabı yorum satırlarında yaşar ve hata yaptığında veri yarışı (data race) ortaya çıkar — yeniden üretilmesi en zor bug sınıfı. Rust'ın iddiası radikaldir: güvenli kodda veri yarışı derleme zamanında imkânsızdır. Bu, ownership kurallarının ve iki işaretleyici trait'in (Send, Sync) doğal bir sonucudur.

Önce tercih edilen kalıp mesajlaşmadır: veriyi paylaşmak yerine sahipliğini bir kanal (channel) üzerinden gönderirsin. "Belleği paylaşarak iletişim kurma, iletişim kurarak belleği paylaş" felsefesi. Paylaşımlı durum gerçekten kaçınılmazsa Arc<Mutex<T>> kullanırsın — ama burada bile veriye mutex'i kilitlemeden erişemezsin, çünkü Mutex::lock() sana ancak kilitliyken geçerli bir &mut verir.

// C++: mutex ve veri AYRI — kilitlemeyi unutmak derlenir
std::mutex m;
int sayac = 0;          // koruma sadece konvansiyon
sayac++;                // mutex'i unuttun: veri yarışı, derleyici sessiz

// Rust: veri mutex'in İÇİNDE — kilitlemeden erişemezsin
use std::sync::{Arc, Mutex};
let sayac = Arc::new(Mutex::new(0));
{
    let mut g = sayac.lock().unwrap(); // kilit alındı
    *g += 1;                            // erişim ancak kilitliyken
} // g düşünce kilit otomatik bırakılır (Drop)

Farkı gör: C++'ta mutex ile koruduğu veri ayrı yaşar, ikisini birbirine bağlayan tek şey programcının niyetidir. Rust'ta veri mutex'in içine konur, dolayısıyla veriye erişmenin tek yolu kilidi almaktır. Üstelik kilit, kilit nesnesi (MutexGuard) kapsamdan çıkınca otomatik bırakılır — C++'taki "unutulan unlock" bug'ı yapısal olarak imkânsızdır.

09 Öğrenme yol haritası

Doğru sırayla öğrenirsen geçiş haftalar, yanlış sırayla aylar sürer; önce ownership'i içselleştir, kestirme kaçışlardan uzak dur ve küçük gerçek bir proje yaz.

Önerilen öğrenme sırası, her adımın bir öncekine yaslanacak şekilde tasarlandı. Bu sırayı atlamak — örneğin ownership'i tam oturtmadan trait'lere geçmek — tam olarak "borrow checker'la güreşme" dönemini uzatır.

ownership/borrow → enum/Option/match → Result/? → trait/generics →
koleksiyon/iterator → lifetimes → smart pointer (Box/Rc/Arc) → eşzamanlılık

Şimdi madalyonun diğer yüzü: erken kaçış tuzakları. Bunlar Rust'ı zorlaştıran değil, öğrenmeni geciktiren kestirmelerdir. Hepsi "borrow checker'a teslim olmamak için ödenen rüşvet"tir ve hepsi öğrenmeyi engeller.

Teori kadar pratik şart: küçük, gerçek bir proje yaz. "Hello world"den sonra en iyi öğretici, somut bir araç yapmaktır. Önerilen ilk projeler: bir komut satırı aracı (örn. grep benzeri bir arama, log filtreleyici, dosya istatistikçisi), basit bir HTTP istemcisi, ya da bir JSON/CSV dönüştürücü. Bu projeler ownership, Result, iterator ve string tiplerinin hepsine aynı anda dokunur — yani bu rehberin tamamını pratiğe döker.